#opg $OPG Есть одна вещь, которую я никак не могу понять. Приходит запрос от AI — и его видят десятки узлов. Кто принимает?
Если “кто быстрее, тот и берет”, то у сети всегда будут дела у быстрых, а медленным вечно не достается работы. В итоге останутся только два-три крупных игрока, а остальные узлы просто “голодают”. И тогда какая вообще децентрализация.
В белой книге OpenGradient предложено решение: лотерея (жеребьевка).
Это не просто случайный рандом. Система берет хэш текущего блока плюс ID этого запроса и отправляет всё в некий модуль под названием VRF, который вычисляет случайное число. Затем это случайное число используют, чтобы упорядочить все онлайн-узлы. Узел, который в списке первый, получает приоритет и забирает заказ. Он должен в заданный срок передать результат и доказательство. Если он просрочит или будет мошенничать — очередь передается второму месту, и так далее.
Суть в том, что это случайное число проверяемое. Узлы не могут жульничать, потому что логика сортировки публичная, и любой может пересчитать всё заново. В белой книге написано, что для подтверждения корректности генерации случайного числа используются доказательства с нулевым разглашением (zero-knowledge). Ты хочешь заранее узнать, кто получит следующий запрос? Не получится.
Раньше я смотрел другой проект, где тоже внедряли VRF, но там сортировку все равно “обгоняли”. Потом выяснилось, что случайное зерно (seed) можно было предсказать заранее. В OpenGradient они “связывают” seed с хэшем блока: хэш блока невозможно предсказать, так что дыру закрыли.
Но у этой конструкции есть неприятный момент. Если узел намеренно сделает так, чтобы операция не успела вовремя (сознательно просрочит), то его сразу не накажут залогом — его просто временно выкинет из очереди. Несколько раз подряд подрядная просрочка должна произойти, прежде чем сработает наказание. В белой книге это называют “мягким наказанием” (soft penalty). Я понимаю: из-за дрожания/флаттера сети (network jitter) у всех может быть просрочка, и наказывать деньгами “с первого раза” слишком жестко. Но при этом появляется пространство для злоупотреблений: кто-то может намеренно многократно просрочивать, чтобы замедлять общую эффективность. Тебе это ничем не остановить, пока оно не дойдет до порога наказания.
В белой книге не указано конкретно, сколько раз можно просрочить и какой порог наказания — думаю, это оставили на настройку после запуска основной сети, исходя из реальной ситуации.
В общем, мне кажется, направление с лотерейным механизмом верное, но он защищает от порядочных, а не от подлецов. Если попадется тот, кто специально “тормозит багами”, возможно, придется полагаться на жалобы сообщества.
А ты как думаешь? Ты считаешь такой способ сортировки справедливым? Добро пожаловать критиковать.@OpenGradient
Если “кто быстрее, тот и берет”, то у сети всегда будут дела у быстрых, а медленным вечно не достается работы. В итоге останутся только два-три крупных игрока, а остальные узлы просто “голодают”. И тогда какая вообще децентрализация.
В белой книге OpenGradient предложено решение: лотерея (жеребьевка).
Это не просто случайный рандом. Система берет хэш текущего блока плюс ID этого запроса и отправляет всё в некий модуль под названием VRF, который вычисляет случайное число. Затем это случайное число используют, чтобы упорядочить все онлайн-узлы. Узел, который в списке первый, получает приоритет и забирает заказ. Он должен в заданный срок передать результат и доказательство. Если он просрочит или будет мошенничать — очередь передается второму месту, и так далее.
Суть в том, что это случайное число проверяемое. Узлы не могут жульничать, потому что логика сортировки публичная, и любой может пересчитать всё заново. В белой книге написано, что для подтверждения корректности генерации случайного числа используются доказательства с нулевым разглашением (zero-knowledge). Ты хочешь заранее узнать, кто получит следующий запрос? Не получится.
Раньше я смотрел другой проект, где тоже внедряли VRF, но там сортировку все равно “обгоняли”. Потом выяснилось, что случайное зерно (seed) можно было предсказать заранее. В OpenGradient они “связывают” seed с хэшем блока: хэш блока невозможно предсказать, так что дыру закрыли.
Но у этой конструкции есть неприятный момент. Если узел намеренно сделает так, чтобы операция не успела вовремя (сознательно просрочит), то его сразу не накажут залогом — его просто временно выкинет из очереди. Несколько раз подряд подрядная просрочка должна произойти, прежде чем сработает наказание. В белой книге это называют “мягким наказанием” (soft penalty). Я понимаю: из-за дрожания/флаттера сети (network jitter) у всех может быть просрочка, и наказывать деньгами “с первого раза” слишком жестко. Но при этом появляется пространство для злоупотреблений: кто-то может намеренно многократно просрочивать, чтобы замедлять общую эффективность. Тебе это ничем не остановить, пока оно не дойдет до порога наказания.
В белой книге не указано конкретно, сколько раз можно просрочить и какой порог наказания — думаю, это оставили на настройку после запуска основной сети, исходя из реальной ситуации.
В общем, мне кажется, направление с лотерейным механизмом верное, но он защищает от порядочных, а не от подлецов. Если попадется тот, кто специально “тормозит багами”, возможно, придется полагаться на жалобы сообщества.
А ты как думаешь? Ты считаешь такой способ сортировки справедливым? Добро пожаловать критиковать.@OpenGradient