Нет, не требует. Это работает во всех сетях, которые поддерживаются Layer Zero. А сам по себе OFT - это токен, который будет построен на базе Layer Zero, то есть будет использовать механизм обмена сообщениями между чейнами, чтобы поддерживать свой supply.
Да, есть такое! Я при чем сначала столкнулся с тем, что расширение метамаск перестал давать перейти на страничку Curve. Кто-то даже ишью успел создать на разблокировку Curve. А потом увидел новость про взлом домена.
> вы можете совершенно безопасно располагать не менееэлементов данных размером слот в каждом таком массиве
Мне просто стало интересно, сколько будут занимать такие данные, жпт говорит, что это. примерно ~10⁷⁰ гигабайт. Это просто физически невозможно провернуть в Ethereum. Это огромное число.
Что касается маппингов
На сколько я понимаю коллизии могут возникнуть в использовании keccak256, но не mapping, потому что mapping использует хеш(key, slot). Так как для получения коллизии нужен один mapping, в котором два ключа дадут одинаковый хеш.
Но тут у меня вопрос, на сколько симуляция на урезанном адресном пространстве валидно? Симуляция keccak256 на K < 256 битах не отражает реальность, потому что в EVM хеш всегда 256-битный на сколько я понимаю.
На мой взгляд бояться наступления коллизий надо при использовании assembly вставок. Вот там, когда ручками по слотам ходишь легко допустить ошибку.
Для нас было приятным сюрпризом, что некоторые страны уже сейчас готовы принимать документы с блокчейн-площадок — отчеты про отчисления, сделанные в крипте!
Тут наверное соглашусь, мне интерфейс у AAVE тоже больше нравится, даже цветовая схема глазу приятнее. С другой стороны - это же субъективно. Хотя в последнее время они стали очень похоже, даже взять минюшки (Dashboard, Markets) почти одинаковые.
Но вот, что касается смартов, тут я компаундом восхищаюсь больше. Мне совсем не нравится организация библиотек на ровне кода у Aave, когда вся бизнес логика распихана по библиотекам, из-за этого очень много данных передается во внутренних функциях.
Здесь не подскажу, надо ковырять страницу полимаркета дальше, что они там делают, чтобы выгрузить и показать все, что касается конкретного голосования. Нужно понимать ,что CLOB - это апишка по работе с ордербуком. А то, как полимаркет работает со своей страницей может отличаться.
Согласно документации. В запросе `GET {clob-endpoint}/markets?next_cursor={next_cursor}`
Первый запрос, вы next_cursor не знаете. Но он придет вам в ответе на запрос без параметра `GET {clob-endpoint}/markets`. Вот в таком виде `"next_cursor": "NjAw"`. Это взято из json ответа. Располагается это поле в конце. Все согласно документации.
Для второго запроса нужно взять полученный next_cursor и подставить в запрос. Вот таким образом `https://clob.polymarket.com/markets?next_cursor=MzAw`. В ответе придет следующий next_cursor и так далее. Пока next_cursor не будет равен видимо значению "LTE". Это я не проверял, до конца все события не выгружал.
В API про condition_id только "id of market which is also the CTF condition ID"
Все верно, CTF (gnosis conditional token framework) отвечает за токенизацию исходов. Если просто, то под каждый исход создается некоторое количество ERC-1155 токена. Поэтому condition ID создается в недрах смарт-контрактов CTF. А потом уже он используется полимаркетом в апишке, в своем CLOB, может быть где-то еще.
Если начать ковыряться, как conditionID генерируется, то в смартах CTF можно найти вот эту функцию. По ней видно, что conditionId - это хеш от трех переменных: - адреса оракула, который рассчитает результат события - questionId, набор байт, которые представляют сам вопрос, прогноз, как угодно его можно назвать. - outcomeSlotCount, количество исходов для questionId. В polymarket это бинарная история - исходы в основном "да" или "нет".
Сам процесс создания нового голосования (conditionId) - это история ручная, в дискорде где-то есть обсуждение и после обсуждения, протокол сам создает событие (прогноз предсказание), то есть сам посылает транзакцию на смарт-контракты. В интерфейсе у них нет возможности добавить любое событие.
next_cursor - это для пагинации маркетов. Там за раз можно выгрузить не все количество маркетов. В ответе на запрос придет информация о следующем next_cursor (конец пагинации или есть что еще выгружать).
Страницу загружал туже самую, что и вы https://polymarket.com/event/presidential-election-winner-2024?tid=1730210729226. Смотрел в chrome на винде. Сейчас проверил в chrome, но на mac. И запрос такой не вижу, но зато есть подключение по websocket wss://ws-subscriptions-clob.polymarket.com/ws/market. Там тоже можно выдернуть condition_id, только он market называется.
Да нет, все правильно делаете. Отправил вам скриншоты на почту.
В любом случае в API есть endpoint, который позволяет выгрузить все маркеты и найти нужные вам. Это чтобы не пришлось парсить страничку полимаркета каким-то образом.
(почему-то аналогичный запрос для Харрис отсутствует),
Его нет потому что нужно переключиться на рынок Харрис скорее всего (Это предположение, я не проверял). Чтобы Харис была в правом окошке, где можно сделать ставку за нее.
Повсеместно. Мы активно используем. Наверное считаем это за своего рода style guide. Мое лично мнение, что это полезно, облегчает чтение, понимание кода.
Я кстати даже никогда об этом не задумывался, как-то сразу начал использовать и все. Может быть повлияла насмотренность на известные проекты: Uniswap, Aave, OpenZeppelin и т.д. Тут же в принципе, в работе твоих контрактов, так или иначе, очень часто используется OZ и невольно перенимаешь стиль.
Нет, просто поковырялся в консоли разработчика, во вкладке Network. Там запрос приходит "https://polymarket.com/_next/data/l7XOx0e7h87Mr5hivQWHi/en/markets.json". И в response этого запроса можно поиском найти по полю "conditionId".
То, что касается данных по голосованию (Трамп и Харрис). Исходы можно получить из информации о маркете. Посмотрите апишку. Нужно проверять, все ли там есть по данным, что вам нужно.
А вот что касается интерактивной карты, в апишке я не встречал, это скорее всего какая-то уникальная история только для выборов. Единственное, что здесь можно посоветовать - это обратиться в дискорд Polymarket к разработчикам.
одно из ключевых ограничений Account Abstraction заключается в том, что он не совместим с традиционными кошельками, такими как MetaMask.
Вот здесь не соглашусь. Для АА вполне можно использовать обычный metamask для идентификации пользователя. В этом плане пользователю с метамаском не нужно ничего придумывать, он точно также пользуется свои кошельком, чтобы подписывать транзакции (точнее userOperations) для своего абстрактного акаунта, эта подпись потом будет разбираться на контрактах и олицетвораять пользователя с его контрактом кошелька. Другое дело, если мы хотим заменить идентификацию пользователя в АА на что-то другое, например на обычную почту. Но тут все равно без EOA никак (точнее потенциал на замену ECDSA есть, но я пока не встречал что-то другое, поделитесь, если есть примеры), он любым способом генерится для пользователя, как ни крути, только для этого используют еще сторонние сервисы: MagicLink, Fireblocks и так далее.
Хотел еще поделиться, что сложность АА легко нивелируется использованием готовых решений: Alchemy, ZeroDev, Biconomy, что-то там от gnosis и другие. Тут на любой вкус с разными прайсами и стандартами поверх ERC-4337 (Это еще стандарты ERC-6900, ERC-7579). Там уже сложность, если тебе не хватает контрактов кошельков под АА готовых, то тогда надо разобраться, как добавить своей логики.
В конце добавлю, что ERC-4337 разрабатывался при поддержки и консультациях ребят из GSN) Yoav Weiss, Dror Tirosh, Shahaf Nacson, Alex Forshtat, если посмотреть их профили, они все в организации OpenGSN. Так что железный человек и человек-паук и тут дружат.
Интересно, как бы мог проходить процесс перехода на новую криптографию в запущеной сети (я так понял HL - это же концепт?), когда кто-то обновился до новой версии, а кто-то нет. И что выбрать: делать вечную обратную совместимость с RSA или принудительно заставлять делать переход на постквантовую криптографию? Просто если часть участников сети продолжат использовать RSA, то и от взлома они не защищены.
При замене доказательства работы на доказательство владения возникнет дополнительная сложность с цепочками осколков (шардингом). Это отдельные блокчейн цепочки, которые позволяют масштабировать сеть ETH и ускоряют её работу. Существует 64 цепочки осколков, и у них у всех должно быть единое понимание состояния сети. В результате необходима дополнительная координация, которую будет выполнять Beacon Chain.
Сеть Beacon Chain получает информацию о состоянии шардов и делает ее доступной для других цепочек шардов, чтобы сеть могла оставаться синхронизированной. Сеть Beacon также управляет валидаторами, начиная с регистрации поставленных ими депозитов до выдачи наград и штрафных санкций.
Подозреваю, что здесь путаница. Либо я чего-то не понимаю. Beacon Chain работает на уровне консенсуса. По сути, это название оригинального блокчейна на PoS, запущенного в 2020 году для перехода с PoW. Отвечает за обработку блоков и аттестации, штрафы, запуск новых форков и так далее. Это написано на сайте Ethereum.
Теперь про шардинг. Я не нашел где сказано, что существует "64 цепочки осколков" и "координирует это beacon chain". Можно ссылку на ресурс и на место в этом ресурсе?
Я предполагаю, что то о чем у вас написано могло бы быть на уровне исполнения, но Beacon Chain там не работает, а значит, что тезис неправильный. Более того, на сколько я знаю концепт шардинга в таком виде не реализован. Реализован промежуточный вариант Proto-Danksharding. Это EIP-4844: Shard Blob Transactions. А он же вообще не про разделение цепочки, там ключевое обновление это blobs за место calldata для роллапов. Чтобы они могли свои пруфы транзакций писать в эфир дешевле, за счет того, что blobs хранилище очищаемое через какое-то время. А им этого времени достаточно, чтобы подтвердить свои транзакции. И благодаря этому недавно на всех роллапах транзакции стали резко дешевле.
Нет, не требует. Это работает во всех сетях, которые поддерживаются Layer Zero. А сам по себе OFT - это токен, который будет построен на базе Layer Zero, то есть будет использовать механизм обмена сообщениями между чейнами, чтобы поддерживать свой supply.
Да, есть такое! Я при чем сначала столкнулся с тем, что расширение метамаск перестал давать перейти на страничку Curve. Кто-то даже ишью успел создать на разблокировку Curve. А потом увидел новость про взлом домена.
Красивая конечно теория!
элементов данных размером![]()
слот в каждом таком массиве
Что касается массивов
> вы можете совершенно безопасно располагать не менее
Мне просто стало интересно, сколько будут занимать такие данные, жпт говорит, что это. примерно ~10⁷⁰ гигабайт. Это просто физически невозможно провернуть в Ethereum. Это огромное число.
Что касается маппингов
На сколько я понимаю коллизии могут возникнуть в использовании keccak256, но не mapping, потому что mapping использует хеш(key, slot). Так как для получения коллизии нужен один mapping, в котором два ключа дадут одинаковый хеш.
Но тут у меня вопрос, на сколько симуляция на урезанном адресном пространстве валидно? Симуляция keccak256 на K < 256 битах не отражает реальность, потому что в EVM хеш всегда 256-битный на сколько я понимаю.
На мой взгляд бояться наступления коллизий надо при использовании assembly вставок. Вот там, когда ручками по слотам ходишь легко допустить ошибку.
А как это дерево решает проблему реальных данных? Как на смартах события рассчитываются? Кому сколько выплат положено?
У Polymarket например отдельный оракул для этого под названием UMA.
Не подскажите, что это за страны?
Тут наверное соглашусь, мне интерфейс у AAVE тоже больше нравится, даже цветовая схема глазу приятнее. С другой стороны - это же субъективно. Хотя в последнее время они стали очень похоже, даже взять минюшки (Dashboard, Markets) почти одинаковые.
Но вот, что касается смартов, тут я компаундом восхищаюсь больше. Мне совсем не нравится организация библиотек на ровне кода у Aave, когда вся бизнес логика распихана по библиотекам, из-за этого очень много данных передается во внутренних функциях.
Есть сервисы, которые позволяют купить опцион и захеджировать позицию поставщика ликвидности на Uniswap V3?
Здесь не подскажу, надо ковырять страницу полимаркета дальше, что они там делают, чтобы выгрузить и показать все, что касается конкретного голосования. Нужно понимать ,что CLOB - это апишка по работе с ордербуком. А то, как полимаркет работает со своей страницей может отличаться.
Согласно документации. В запросе `GET {clob-endpoint}/markets?next_cursor={next_cursor}`
Первый запрос, вы next_cursor не знаете. Но он придет вам в ответе на запрос без параметра `GET {clob-endpoint}/markets`. Вот в таком виде `"next_cursor": "NjAw"`. Это взято из json ответа. Располагается это поле в конце. Все согласно документации.
Для второго запроса нужно взять полученный next_cursor и подставить в запрос. Вот таким образом `https://clob.polymarket.com/markets?next_cursor=MzAw`. В ответе придет следующий next_cursor и так далее. Пока next_cursor не будет равен видимо значению "LTE". Это я не проверял, до конца все события не выгружал.
Все верно, CTF (gnosis conditional token framework) отвечает за токенизацию исходов. Если просто, то под каждый исход создается некоторое количество ERC-1155 токена. Поэтому condition ID создается в недрах смарт-контрактов CTF. А потом уже он используется полимаркетом в апишке, в своем CLOB, может быть где-то еще.
Если начать ковыряться, как conditionID генерируется, то в смартах CTF можно найти вот эту функцию. По ней видно, что conditionId - это хеш от трех переменных:
- адреса оракула, который рассчитает результат события
- questionId, набор байт, которые представляют сам вопрос, прогноз, как угодно его можно назвать.
- outcomeSlotCount, количество исходов для questionId. В polymarket это бинарная история - исходы в основном "да" или "нет".
Сам процесс создания нового голосования (conditionId) - это история ручная, в дискорде где-то есть обсуждение и после обсуждения, протокол сам создает событие (прогноз предсказание), то есть сам посылает транзакцию на смарт-контракты. В интерфейсе у них нет возможности добавить любое событие.
next_cursor - это для пагинации маркетов. Там за раз можно выгрузить не все количество маркетов. В ответе на запрос придет информация о следующем next_cursor (конец пагинации или есть что еще выгружать).
Страницу загружал туже самую, что и вы https://polymarket.com/event/presidential-election-winner-2024?tid=1730210729226. Смотрел в chrome на винде. Сейчас проверил в chrome, но на mac. И запрос такой не вижу, но зато есть подключение по websocket wss://ws-subscriptions-clob.polymarket.com/ws/market. Там тоже можно выдернуть condition_id, только он market называется.
Да нет, все правильно делаете. Отправил вам скриншоты на почту.
В любом случае в API есть endpoint, который позволяет выгрузить все маркеты и найти нужные вам. Это чтобы не пришлось парсить страничку полимаркета каким-то образом.
Его нет потому что нужно переключиться на рынок Харрис скорее всего (Это предположение, я не проверял). Чтобы Харис была в правом окошке, где можно сделать ставку за нее.
Повсеместно. Мы активно используем. Наверное считаем это за своего рода style guide. Мое лично мнение, что это полезно, облегчает чтение, понимание кода.
Я кстати даже никогда об этом не задумывался, как-то сразу начал использовать и все. Может быть повлияла насмотренность на известные проекты: Uniswap, Aave, OpenZeppelin и т.д. Тут же в принципе, в работе твоих контрактов, так или иначе, очень часто используется OZ и невольно перенимаешь стиль.
Нет, просто поковырялся в консоли разработчика, во вкладке Network. Там запрос приходит "https://polymarket.com/_next/data/l7XOx0e7h87Mr5hivQWHi/en/markets.json". И в response этого запроса можно поиском найти по полю "conditionId".
Вот это маркет на Трампа.
Вот это маркет на Харрис.
Это простые GET запросы. По типу {clob-endpoint}/markets/{condition_id}. ConditionId я взял прямо из запросов, которые делает страничка Polymarket.
То, что касается данных по голосованию (Трамп и Харрис). Исходы можно получить из информации о маркете. Посмотрите апишку. Нужно проверять, все ли там есть по данным, что вам нужно.
А вот что касается интерактивной карты, в апишке я не встречал, это скорее всего какая-то уникальная история только для выборов. Единственное, что здесь можно посоветовать - это обратиться в дискорд Polymarket к разработчикам.
Знаю, что в Solana АА работает из коробки.
Вот здесь не соглашусь. Для АА вполне можно использовать обычный metamask для идентификации пользователя. В этом плане пользователю с метамаском не нужно ничего придумывать, он точно также пользуется свои кошельком, чтобы подписывать транзакции (точнее userOperations) для своего абстрактного акаунта, эта подпись потом будет разбираться на контрактах и олицетвораять пользователя с его контрактом кошелька. Другое дело, если мы хотим заменить идентификацию пользователя в АА на что-то другое, например на обычную почту. Но тут все равно без EOA никак (точнее потенциал на замену ECDSA есть, но я пока не встречал что-то другое, поделитесь, если есть примеры), он любым способом генерится для пользователя, как ни крути, только для этого используют еще сторонние сервисы: MagicLink, Fireblocks и так далее.
Хотел еще поделиться, что сложность АА легко нивелируется использованием готовых решений: Alchemy, ZeroDev, Biconomy, что-то там от gnosis и другие. Тут на любой вкус с разными прайсами и стандартами поверх ERC-4337 (Это еще стандарты ERC-6900, ERC-7579). Там уже сложность, если тебе не хватает контрактов кошельков под АА готовых, то тогда надо разобраться, как добавить своей логики.
В конце добавлю, что ERC-4337 разрабатывался при поддержки и консультациях ребят из GSN) Yoav Weiss, Dror Tirosh, Shahaf Nacson, Alex Forshtat, если посмотреть их профили, они все в организации OpenGSN. Так что железный человек и человек-паук и тут дружат.
Интересно, как бы мог проходить процесс перехода на новую криптографию в запущеной сети (я так понял HL - это же концепт?), когда кто-то обновился до новой версии, а кто-то нет. И что выбрать: делать вечную обратную совместимость с
RSAили принудительно заставлять делать переход на постквантовую криптографию? Просто если часть участников сети продолжат использовать RSA, то и от взлома они не защищены.Подозреваю, что здесь путаница. Либо я чего-то не понимаю.
Beacon Chain работает на уровне консенсуса. По сути, это название оригинального блокчейна на PoS, запущенного в 2020 году для перехода с PoW. Отвечает за обработку блоков и аттестации, штрафы, запуск новых форков и так далее. Это написано на сайте Ethereum.
Теперь про шардинг. Я не нашел где сказано, что существует "64 цепочки осколков" и "координирует это beacon chain". Можно ссылку на ресурс и на место в этом ресурсе?
Я предполагаю, что то о чем у вас написано могло бы быть на уровне исполнения, но Beacon Chain там не работает, а значит, что тезис неправильный. Более того, на сколько я знаю концепт шардинга в таком виде не реализован. Реализован промежуточный вариант Proto-Danksharding. Это EIP-4844: Shard Blob Transactions. А он же вообще не про разделение цепочки, там ключевое обновление это blobs за место calldata для роллапов. Чтобы они могли свои пруфы транзакций писать в эфир дешевле, за счет того, что blobs хранилище очищаемое через какое-то время. А им этого времени достаточно, чтобы подтвердить свои транзакции. И благодаря этому недавно на всех роллапах транзакции стали резко дешевле.
P.S. Кажется я нашел место где вы это взяли - это русская версия вот этой страницы: https://ethereum.org/ru/developers/docs/consensus-mechanisms/pos/. Но фишка в том, что, если переключить на английский язык, то она вообще другая. https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/