Czy tworzenie rynku można uogólnić poza handel? W nowym poście opisuję nowy mechanizm, który pozwala twórcom rynku nie tylko ustalać ceny, ale także efektywnie alokować ograniczone zasoby w każdym zdecentralizowanym systemie obliczeniowym.

Powiedzmy, że masz kilka żądań obliczeniowych (np. transakcje, żądania oracle itp.) oraz kilka węzłów, które mogą wykonać to żądanie. Jak możemy ustalić ceny i przydzielić żądania obliczeniowe do węzłów w obecności złożonych (np. zasobów, stanu, równoległości) ograniczeń?

Chcielibyśmy w idealnym świecie efektywnie wykorzystać ograniczone zasoby sieci i oferować ceny, które będą akceptowane przez użytkowników i węzły, a jednocześnie nie będą wyzyskujące. Dodatkowo chcielibyśmy oferować ustalone ceny, aby uczestnicy mogli mieć prosty interfejs użytkownika (jak w Uberze), zamiast musieć strategicznie licytować.

Jednak bez ofert sieć nie ma informacji, aby ocenić efektywność alokacji swoich zasobów. Rozwiązujemy to, rekrutując animatorów rynku, którzy mogą oszacować parametry popytu i podaży. Jednak wykorzystanie ich bez oddawania im wszystkich zysków z handlu jest dość trudne.

Z jednym animatoriem rynku możemy zachęcić do efektywnej alokacji, pozwalając animatorowi ustalać ceny i zatrzymywać marżę. Jednak animator będzie pobierał od użytkowników wysokie ceny i płacił węzłom niskie nagrody, zatrzymując wszystkie zyski z handlu. Tak właśnie dzieje się na rynkach takich jak Uber.

Jednak przy wielu twórcach nie jest jasne, jak wybrać najlepszą propozycję, ponieważ mechanizm nie ma informacji na temat parametrów podaży/popytu. Głównym wkładem tego posta jest nowy mechanizm, który stawia twórców w starannej konkurencji, aby osiągnąć efektywność bez wydobycia.

Mechanizm kolejno rozważa propozycje makerów, z bieżącą "najlepszą" propozycją. Jeśli następna propozycja oferuje wyraźnie lepsze ceny dla konfliktujących uczestników, bieżąca propozycja może próbować dopasować ceny, pogarszając je dla uczestników, którzy nie są w konflikcie.

Obecna najlepsza propozycja jest zastępowana, jeśli nie jest w stanie dopasować ceny. W równowadze mechanizm zwraca plan alokacji i wyceny zasobów, który jest efektywny i będzie akceptowany przez użytkowników i węzły bez bycia eksploatacyjnym.

Specjalne podziękowania dla @0xemperor @noamnisan @0xQTpie @ArshanKhanifar @PGarimidi @MaxResnick1 @bahrani_maryam @ckartik_ i innych za opinie, oraz @achalvs za projekt.