Случайността е критична за осигуряване на справедливи, непредсказуеми и непредубедени резултати в разпределени системи, но въпреки това може да бъде обект на манипулация без подходящ дизайн.
Проверима случайност във Web3
Проверимата произволност във веригата е ключов ресурс в Web3 приложенията. Това важи особено за онлайн лотарии, блокчейн игри, NFT сечене и генериране на характеристики, избор на лидер, разпределение на цифрови ресурси и много други. Това е съставката, която изравнява игралното поле за участниците, така че резултатите да не могат да бъдат предвидени от никого, преди да се появят, особено операторите на възли или други участници, които могат да се опитат да получат асиметрични знания и предимства.
Достъпът до проверими източници на произволност позволява и други криптографски протоколи, като многостранни изчисления и доказателства с нулево знание. Тези протоколи имат разнообразие от свои собствени приложения, с употреби, включително машинно обучение за запазване на поверителността, създаване на ZK Bridges и проверими изчисления. Единственият въпрос сега е: Какво е проверима случайност?
Какво е „проверима“ или „добра“ случайност?
В предишният ни блог, заявихме, че проверимата или „добрата“ случайност, която води до генериране на наистина произволно число, е:
- Непредвидима: Никой не може да изчисли числото предварително.
- Безпристрастна: Случайното число не може да бъде отклонено, за да направи определени числа по-вероятно да се появят от други (напр. числото винаги е четно или винаги нечетно).
- Публично проверима: Всеки може да провери дали произволното число е правилно генерирано.
В нашата бяла книга за разпределена проверима произволна функция (dVRF) обсъдихме, че протоколът за услугата за произволност Supra dVRF удовлетворява горните три свойства и следователно осигурява добра произволност. Сега основният въпрос е:
Как да идентифицирате дали протокол за услуга за случайност генерира проверима „добра“ случайност или „лоша“ (т.е. непроверима) случайност?
В поредица от блогове ще изследваме как да генерираме и използваме проверима произволност в пространството Web3. Започвайки с публикацията, ще се потопим в протоколите за обслужване на случаен принцип, използвайки схеми за ангажиране и разкриване. Ние наричаме по-широката концепция за ангажиране-разкриване като парадигма на ангажиране-разкриване.
Анализ на парадигмата Commit-Reveal
Нека започнем с обикновената парадигма за ангажиране и разкриване, за да твърдим, че е невъзможно да се получи безпристрастна произволност в тази парадигма. По-късно ще проучим същите уязвимости, които ще причинят проблеми в парадигмата за ангажиране и разкриване, в която се внедряват интелигентните договори.
В обикновената парадигма за ангажиране и разкриване, доставчикът на произволност и потребителят се ангажират с произволни стойности x и s, използвайки хеш функция H. При размяна на ангажиментите доставчикът и потребителят разкриват x и s един на друг. И потребителят, и доставчикът проверяват разкритите стойности спрямо ангажиментите. Ако ангажиментите се потвърдят, те изчисляват случайността rand=H(x, s). Ние илюстрираме тази парадигма по-долу:
Фигура 1. Блок-схема на парадигмата Commit-Reveal
Тъй като потребителят получава x от доставчика след размяна на ангажиментите, потребителят може предварително да изчисли изхода. Това е основен дефект в дизайна, тъй като потребителят може да продължи/забави протокола в Стъпка 4, ако резултатът е благоприятен/неблагоприятен. Това ще позволи на потребителя да увеличи максимално печалбата си. Доставчикът не може да завърши изпълнението, без да получи s от потребителя, тъй като s остава в тайна. Следователно изходът може да бъде предубеден.
Това е нежелателно в пространството Web3, където случайността на потребителя във веригата се генерира в идеалния случай от доставчика, след като потребителят е инициирал заявката за произволност. Това е независимо дали потребителят ще продължи/прекъсне протокола по-късно.
Невъзможност и преодоляване
Невъзможно е да се постигне безпристрастна произволност с помощта на commit-reveal без никакво надеждно предположение. Това беше показано от Cleve, че две страни не могат да генерират безпристрастна произволност без никакви предположения. Това е така, защото една от страните винаги ще получи своя изход първи и след това ще реши да прекрати протокола, ако изходът е неблагоприятен, подобно на атаката, показана по-рано.
В пространството Web3 обаче потребителят и доставчикът имат достъп до интелигентни договори. Интелигентните договори действат като доверена страна за извършване на правилно изчисление върху обществени стойности. Услугата за случайност използва интелигентни договори, за да генерира непредсказуема, непредубедена и публично проверима случайност.
Това обаче е по-лесно да се каже, отколкото да се направи, особено в парадигмата на ангажиране-разкриване. Ние показваме, че съществуващата услуга за произволност на PythVRF се основава на тази парадигма и внедрява интелигентни договори, но те не успяват да произведат непредубеден случаен изход.
Уязвимост в Pyth VRF
PythVRF протоколът работи в парадигмата за ангажиране и разкриване, където доставчикът първоначално се ангажира с поредица от произволни стойности (x1, x2,…xN) на Entropy Smart Contract (SC). НС съхранява тези ангажименти.
Потребителят инициира заявка, като избере произволна стойност s. Потребителят се ангажира с s като c и след това изпраща c на SC. SC съхранява c и присвоява уникален пореден номер — reqid (означен като i в PythVRF) на потребителя. Потребителят изпраща reqid на доставчика чрез HTTP заявка и получава xreqid . Потребителят разкрива (s , xreqid) на Entropy SC.
SC проверява xreqid (спрямо съхранените ангажименти) и c и след това изчислява случайността rand. Протоколът PythVRF може да се визуализира по-долу:
Фигура 2. Блок-схема на протокола PythVRF
Злонамерен потребител атакува протокола, като предварително изчисли rand=H(s, xreqid), след като получи xreqid от доставчика. Ако резултатът е благоприятен, тогава потребителят продължава протокола, в противен случай той прекъсва протокола. Това позволява на потребителя да увеличи максимално шанса си за печалба в онлайн лотарийна игра, където произволността на потребителя се взема под внимание при определянето на победителите.
Със Supra се използва клан от възли вместо един възел. В резултат на това отделните възли не могат да повлияят или задържат произволните изходи, тъй като никой от тях не е в състояние да предвиди резултата предварително. Клиентът не може да предотврати качването на изхода във веригата, след като е инициирал заявката за произволност.
Заключение
Това е първата от поредица публикации в блогове за проверима случайност във веригата. В тази публикация обсъдихме невъзможността за получаване на непредубеден изход в обикновената парадигма за ангажиране и разкриване. След това показахме, че дори при наличието на интелигентни договори има съществуващи протоколи, които не успяват да осигурят безпристрастна произволност.
В следващите няколко публикации ще обсъдим как официално да уловим свойствата на непредсказуемост, непредубеденост и публична проверка, които са от съществено значение за случайността във веригата. След това ще се потопим дълбоко в VRF-базираните и Beacon-базираните подходи за проверима случайност във веригата.
Разгледайте също
- Проверими произволни функции: Честна игра в децентрализиран свят
- Supra Intralayer: Plug-and-Play микроуслуги за крос-чейн икономика
- Захранване на Supra Network: Moonshot Consensus Mechanism
Оригинална статия : линк
