Раньше я обычно по умолчанию считал, что безопасность в сделках в первую очередь зависит от того, насколько платформа достаточно надежна. Если система стабильна и у нее есть механизмы защиты, остальное почти полностью является обязанностью стороны-оператора.
Когда я внимательно изучил документацию Binance P2P, я наткнулся на один момент, из-за которого мне пришлось остановиться. Большинство механизмов защиты созданы не для того, чтобы заменить пользователя в принятии решений; они спроектированы так, чтобы снижать риски, когда при этом каждая сторона все равно несет ответственность за свои действия.
Сначала я думал, что escrow — это ключевой фактор безопасности. Затем я понял, что escrow лишь удерживает активы во время сделки: он не может проверять содержание переписки за пределами платформы и не может предотвратить ситуацию, когда пользователь отправляет деньги не на тот счет, или подтвердить получение до того, как деньги фактически были получены. Мне пришлось перечитать раздел про обработку споров, чтобы по-настоящему увидеть эти ограничения.
С моей точки зрения на данный момент, Binance P2P не пытается полностью устранить необходимость доверять. Вместо этого система старается уменьшить зависимость от доверия между двумя сторонами сделки, добавляя механизмы escrow, процедуры верификации и регламент разрешения споров. Пользователю по-прежнему нужно доверять Binance в роли посредника-эскроу, который хранит активы во время сделки и исполняет итог при возникновении спора. Реальная разница заключается в том, как более четко распределена ответственность между платформой и пользователем. То, что заставляет меня продолжать размышлять, — не сам механизм escrow, а то, что система становится действительно безопасной только тогда, когда пользователь понимает ее реальные границы. #binancep2pantoan @Binance Vietnam
Был период, когда я по умолчанию считал, что появление крупного фонда в cap table — это очень сильный сигнал. Увидев это название, я обычно начинал верить, что самая сложная часть процесса оценки уже позади.
Но когда я внимательно прочитал детали инвестиций a16z в Babylon, я вдруг начал думать иначе. Объявленное обязательство в размере 15 миллионов долларов было сделано довольно рано, в то время как Trustless Bitcoin Vaults всё ещё находились на стадии testnet, а многие аспекты реализации продолжают дорабатываться. Это заставило меня понять, что речь пока не о подтверждении для уже полностью завершённой системы.
Сначала я воспринимал это вложение как доказательство, но затем заметил, что фактически смешал два разных понятия. С моей точки зрения сейчас, это скорее ставка на дизайнерскую концепцию и способность команды её реализовать, а не утверждение, что все криптографические допущения и допущения безопасности в архитектуре vault, основанной на BitVM3, уже проверены в реальных условиях.
Отсюда у меня появилось больше мыслей о том, как мы читаем рыночные сигналы. Инвесторская организация может потратить огромные ресурсы на due diligence, но этот процесс не может заменить то, что в конечном счёте может подтвердить только сама сеть и реальные пользователи. Похоже, что доверие инвестора и технические доказательства всегда относятся к двум разным уровням оценки. Более важный и сложный вопрос звучит так: в такой ещё очень ранней инфраструктуре, как Babylon, какую долю веса мы должны отдавать доверию фондов, а какую — тому, что со временем и в ходе реальной эксплуатации смогут подтвердить только практика и использование. #baby $BABY @BabylonLabs_io
Я когда-то думал, что для хорошего опыта достаточно, чтобы всё было достаточно быстрым и достаточно интуитивным. Если интерфейс заставляет пользователя ждать слишком долго, я почти автоматически воспринимаю это как место, которое нужно оптимизировать.
Когда я сам попробовал peg-in с помощью signet BTC на Babylon, первое ощущение ничем не отличалось. Подтверждение транзакции, ожидание, двенадцать блоков. Почти два часа экран показывал только то, как растёт количество блоков, и сообщение о том, что vault станет доступен после того, как транзакция получит достаточное число подтверждений. Всё работало корректно, просто я не чувствовал, что именно происходит «за кадром».
Сначала я воспринимал эти двенадцать подтверждений как просто период ожидания. Потом я понял: я отделяю свой опыт от архитектуры системы. Мне пришлось перечитать описание Bitcoin finality, чтобы осознать, что каждый блок — это не просто прошедшее время: каждое новое подтверждение резко снижает вероятность отката транзакции, а стоимость перестроения цепочки заметно растёт. Именно это и является фундаментом, на котором протоколы выше по стеку могут доверять тому, что BTC действительно заблокирован.
С точки зрения, которая у меня сформировалась сейчас, проблема не в том, что Bitcoin «медленный». Более важный вопрос — что интерфейс почти не объясняет пользователю, *почему* ему приходится ждать. Модель доверия системы построена на finality Bitcoin, но на переднем плане появляется лишь индикатор прогресса.
Я пробовал на testnet — так что времени было достаточно, чтобы понаблюдать. Для человека, который блокирует настоящие BTC, это наверняка ощущается совсем иначе. Возможно, дело не в том, как сделать время ожидания короче, а в том, как помочь пользователю увидеть смысл самого того времени, которое он ждёт. #baby $BABY @BabylonLabs_io
Некоторое время я почти по умолчанию считал, что каждый раз, когда рынок говорит о том, что у Bitcoin появилась ещё какая-то «утилитарность» (utility), это означает: BTC реально начали использовать где-то в мейннете. Я редко различал доказанную концепцию и продукт, уже готовый к работе на настоящих капиталах.
Около 2 часов ночи я всё ещё не спал, и открыл дашборд стейкинга только чтобы посмотреть, изменится ли количество моих BTC. Результат, как и ожидалось: ничего. Биткоины по-прежнему были заблокированы по тем же правилам стейкинга Babylon. Ничего неожиданного — в сущности. Затем я заметил кластер фразы «TBV открывает utility для BTC», который довольно плотно встречался под статьями про Babylon. Сначала я тоже подумал, что это значит: BTC уже можно использовать как залог на Aave. Но когда я пролистал посты и перечитал документацию с тем же темпом, я понял, что разобрался быстрее, чем было на самом деле. Babylon с начала июня вынес в публичный тестнет Trustless Bitcoin Vaults, интегрированные с Aave V4. Это техническая валидация, но ещё не протокол, готовый принимать реальные активы.
Чтобы дойти до мейннета, proposal всё равно должен пройти процесс governance Aave — с оценкой рисков, оракулами, лимитами ликвидации и множеством других параметров. Задумался меня не тестнет или мейннет, а то, что иногда рынок отражает будущее, которое уже спроектировано, хотя цепочка всё ещё ждёт последнего шага, чтобы превратить этот дизайн в реальность. #baby $BABY @BabylonLabs_io
Было одно, что я когда-то считал вполне очевидным, когда думал о протоколах lending. Я всегда полагал, что плавающая ставка, зависящая от спроса и предложения, — почти стандартный выбор, потому что залог и ликвидность находятся в одной среде исполнения. Когда все состояния обновляются непрерывно, такая конструкция кажется вполне естественной.
Пока я читал материалы о Trustless Bitcoin Vaults от Babylon и сам проходил через testnet, я наткнулся на деталь, которая заставила меня остановиться. BTC по-прежнему блокируется нативными скриптами Bitcoin, а не помещается в smart contract на другой цепочке. Сначала я воспринял это просто как более безопасный вариант кастодиального хранения.
Чем дальше читал, тем яснее понимал: я слишком упрощал проблему. Пока активы остаются на Bitcoin, многие механизмы, которые в DeFi обычно считаются само собой разумеющимися, нельзя применить в точности без изменений. Дело не в том, что это невозможно — скорее, для работы потребуется больше новых допущений и согласованных компонентов.
От этого мне стало гораздо больше думать о том, какие модели lending можно построить поверх TBV. Возможно, некоторые конструкции будут склоняться к простоте и предсказуемости, а не к максимальной эффективности капитала. Это не столько ограничение самого Bitcoin, сколько следствие попытки сохранить исходную trust model.
Меня все еще волнует не то, какая модель лучше, а то, будут ли при достаточно большом масштабе нативного lending BTC дизайнеры продолжать защищать эту философию или же согласятся добавить дополнительные предположения и допуски доверия ради более высокой финансовой эффективности. #baby $BABY @BabylonLabs_io
Раньше я обычно оценивал протокол по тем уязвимостям, которые могут привести к потере средств. Если нельзя украсть деньги или захватить контроль над сетью, я обычно считал это проблемами реализации, которые скоро будут исправлены.
Но когда я прочитал уведомление о безопасности и обсуждение на GitHub по Babylon, меня остановила одна деталь. Валидатор может отправить Vote Extension, в котором поле block_hash игнорируется. Казалось бы, очень небольшое поле данных, но его достаточно, чтобы другие узлы получали ошибки при проверке сообщения, если этот случай обработан неправильно.
Сначала я подумал, что это просто программный баг, но затем понял, что слишком долго смотрел на последствия и упустил его место в системе. Эта ошибка не позволяет украсть Bitcoin и не создает напрямую другую цепочку. Что она затрагивает — это доступность сети. Валидатор может вызвать runtime panic во время процесса валидации, и если несколько узлов окажутся в таком состоянии одновременно, способность сети поддерживать liveness будет нарушена.
То, о чем я задумался сильнее всего, лежит в другом месте. Babylon заимствует безопасность у Bitcoin через механизмы вроде timestamping и checkpoint, но весь слой оркестрации реализован собственным программным обеспечением Babylon. С моей текущей точки зрения, именно здесь самое интересное для наблюдения. Возможно, вопрос не в том, достаточно ли безопасен Bitcoin, а в том, насколько быстро реализация, связывающая Babylon с Bitcoin, повзрослеет, когда системе придется работать под реальным давлением. #baby $BABY @BabylonLabs_io
Я вошёл в Babylon с довольно естественной мыслью: раз staking открыт, значит я могу участвовать в любой момент, когда мне это будет удобно. Но именно эта мысль чуть не помешала мне успеть к Phase 1.
После того как я внимательно прочитал документацию, я открыл dashboard staking и понял, что Cap 1 ограничен 1.000 BTC. Пакеты stake обрабатываются в порядке, в котором транзакции появляются в Bitcoin blockchain: когда cap заполняется, все последующие транзакции переходят в статус overflow.
Больше всего меня насторожило то, что этот лимит заполняется быстрее, чем я предполагал. С тех пор я начал по-другому смотреть на само понятие «открыт». Babylon действительно открывает staking, но с механизмом FCFS: время, когда ты подключаешься, становится частью условий участия.
То, что мне показалось особенно интересным, — проблема не в дизайне Babylon. Чем больше я читаю, тем сильнее я ценю, как они используют исходный timelock биткоина, а не полагаются на wrapped-актив или какой-то внешний слой доверия.
Чем дальше я читаю, тем больше вижу: этот лимит не было чем-то скрыт. Cap был объявлен заранее, а Phase 1 разворачивали поэтапно. Возможно, то, что я изначально понял неправильно, — это мои собственные ожидания. Я не хочу спешить: я хочу прочитать внимательно и только потом действовать. Но в системе, которая зависит от порядка транзакций в Bitcoin, даже короткий промежуток времени может дать очень серьёзную разницу.
И ещё я всё думаю над таким вопросом: в permissionless-системе, сохраняет ли смысл фраза «открыто для всех», если момент твоего появления решает, будет ли у тебя возможность участвовать? #baby $BABY @BabylonLabs_io
Сегодня я почти весь вечер потратил на то, чтобы вдумчиво всё обдумать: перечитать материалы Babylon, чтобы подготовиться к задаче на CreatorPad. Но то, что заставило меня остановиться, — не механизм Trustless Bitcoin Vaults. Больше всего заставил меня задуматься разрыв между таймлайнами компонентов в этой системе.
Сначала я довольно по умолчанию считал, что vault уже является относительно завершённой частью, а Bitcoin Staking — лишь стартовым этапом. Но чем больше я сверялся с whitepaper, обновлёнными документами и FAQ, тем яснее видел, что картина почти обратная.
Bitcoin Staking прошло через несколько стадий развития и сейчас является наиболее зрелой частью Babylon: объём BTC в стейкинге на mainnet очень велик. В то же время Trustless Bitcoin Vaults, направление, где нативный BTC становится залоговым активом для нового DeFi, пока находится лишь на стадии public testnet. Ещё один момент, который я понял неправильно, — что каждый vault работает не как единый общий пул ликвидности, а построен по модели self-custodial для каждого отдельного пользователя.
Из-за этого у меня возник вопрос: не случалось ли так, что я неосознанно приравнивал степень зрелости протокола стейкинга к готовности Trustless Bitcoin Vaults. Возможно, этот разрыв — абсолютно нормальная вещь в процессе развития продукта, но мне всё равно интересно, как именно он будет восполняться, когда TBV выйдет на mainnet. #baby $BABY @BabylonLabs_io
Раньше я всё ещё думал, что любая новая конструкция должна быть сначала проверена в простой среде. Меньше переменных, меньше давления — и только потом можно расширяться на более крупные экосистемы.
Но когда я перечитал материалы о Trustless Bitcoin Vaults, я наткнулся на одну деталь, которая заставила меня остановиться. Первой DeFi-интеграцией TBV является Aave v4 в сети Ethereum.
Сначала я считал, что это просто выбор с точки зрения экосистемы. Чем больше я читаю, тем сильнее ощущаю, что я, вероятно, смотрел на проблему под другим углом. Ethereum и сейчас остаётся тем местом, где сосредоточена основная часть ликвидности в кредитовании и где реально много пользователей DeFi. Если вы хотите проверить, что «базовый» BTC может участвовать в заимствованиях без Wrapped BTC, без моста или без посредника-кастодиана, то это достаточно строгая среда, чтобы наблюдать, как подобный дизайн работает на практике.
С моей текущей точки зрения примечательно не то, что Babylon выбрали Ethereum. Задуматься заставляет другое: они начали с рынка, где уже есть ликвидность и очень высокие ожидания, а не с среды, где успех может казаться лёгким.
Сегодня я пересмотрел весь поток TBV и сопоставил его с тем, что я когда-то отмечал ранее. Меня привлёк не уровень процентной ставки, а то, что BTC по-прежнему остаётся заблокированным в сети Bitcoin по заранее определённым условиям, а не требует обёртывания или переноса в другую модель с кастодианами.
Возможно, стоит задуматься не о том, был ли Ethereum лучшей точкой старта, а о том, имеет ли ценность дизайн только тогда, когда его сразу проверяют в самой сложной среде. #baby $BABY @BabylonLabs_io
Сначала я тоже думал, что самое примечательное в Babylon — это возможность, которая позволяет Bitcoin участвовать в стейкинге, но чем больше я читаю документацию, тем яснее, что это лишь поверхностный слой всей конструкции.
То, что заставило меня пересмотреть свое мнение, заключается в том, что Babylon не требует моста BTC на другой блокчейн и не опирается ни на wrapped BTC, ни на какую-либо доверенную сторону-кастоди. Bitcoin продолжает оставаться заблокированным в самой сети Bitcoin в модели самокастоди. «Играют» здесь не правом собственности на Bitcoin, а экономическим обязательством, связанным с количеством BTC, прошедших стейкинг. Если валидатор ведет себя неправильно, механизмы Babylon создают условия, позволяющие применить экономические санкции.
С моей текущей точки зрения ценность Babylon не в том, что он добавляет еще одну форму стейкинга. Интереснее другое: как они позволяют сетям Proof-of-Stake наследовать экономическую безопасность от Bitcoin, не меняя ключевые допущения о собственности и модели безопасности Bitcoin. В таком случае Bitcoin перестает быть просто активом для хранения стоимости и может превратиться в экономическую основу безопасности для других систем.
Рынок обычно обращает внимание на то, что можно измерить сразу. Но ценность инфраструктурных кооперационных слоев часто проявляется лишь тогда, когда они постепенно меняют то, как другие строят системы. Возможно, то, что Babylon тестирует, — это не новая модель стейкинга, а способ для других блокчейнов использовать экономическую безопасность Bitcoin, сохраняя при этом саму суть Bitcoin. #baby $BABY @BabylonLabs_io
Раньше я почти по умолчанию считал, что стейкинг всегда означает передачу активов в другую систему. Чтобы активы создавали ценность и обеспечивали безопасность, нужно либо согласиться передать контроль, либо хотя бы довериться новому инфраструктурному уровню. Я привык смотреть на большинство моделей стейкинга именно так.
Пока не прочитал документацию Babylon — один момент заставил меня остановиться. Меня привлёк не сам термин Bitcoin Staking, а то, что биткоин при этом остаётся заблокированным в самой сети Bitcoin, а не требует бриджа на другой блокчейн. Я должен был перечитать описания timelock, EOTS и новый механизм slashing, чтобы понять: эта идея не так проста, как мне казалось.
Сначала я думал, что Babylon просто ищет способ, как встроить Bitcoin в обеспечение безопасности сетей PoS. Затем я понял, что фокус не в перемещении Bitcoin, а в том, как экономическая ценность биткоина может быть использована для защиты другой системы, при этом модель самостоятельного хранения (self-custody) сохраняется. На мой взгляд, реальное различие заключается в попытке отделить custody-ответственность активов от экономической безопасности, вместо того чтобы считать, что эти два понятия всегда должны идти вместе. Это заставило меня пересмотреть trust-модель. Похоже, Babylon не пытается менять сам Bitcoin, а меняет то, как другие сети используют уже существующие у Bitcoin свойства безопасности. Ответственность снова разграничивается, и вместе с этим доверие (trust) тоже смещается. Я по-прежнему чувствую, что не до конца понимаю все последствия этого дизайна. Возможно, более достойный размышления вопрос не в том, какую сеть защищает Bitcoin, а в то, какую вещь на самом деле выбирает защищающая сторона — во что именно она решает доверять. #baby $BABY @BabylonLabs_io
Раньше я воспринимал выпуск стейблкоинов как историю о залоговом обеспечении и об организации-эмитенте. Пока активы достаточно безопасны и есть разумный механизм ликвидации, остальное — просто задача исполнения. Я почти никогда не ставил под сомнение эту предпосылку.
Когда я читаю материалы Babylon, есть одна деталь, из-за которой я вынужден замедлиться. Trustless Bitcoin Vault не пытается превратить биткоин в стейблкоин, и он также не выводит BTC из биткоина так, как это делали многие модели мостов (bridge). Вместо этого он предлагает другой способ, чтобы BTC мог участвовать в финансовых приложениях, при этом сохраняя те условия контроля, которые были заранее определены. Это заставило меня перечитать раздел проектирования больше одного раза. Сначала я думал, что это просто улучшенная модель custody. Затем я понял, что акцент не в том, кто именно хранит активы, а в том, что условия использования и развертывания/выдачи BTC уже закреплены с самого начала и их можно проверить. С точки зрения, которую я сейчас разделяю, реальное отличие заключается в снижении зависимости от одной стороны-хранителя, а не в полном устранении доверия из системы. Чем больше я читаю, тем сильнее вижу, что это проектирование отражает другую предпосылку. Возможно, стейблкоину нужны не только обеспечивающие активы, но и модель контроля, которая уменьшает роль хранителей-посредников. Доверие не исчезает — оно переносится от организации к правилам и допущениям самого протокола.
Я по-прежнему сомневаюсь, заключается ли наибольшая ценность Trustless Bitcoin Vault в самой его функциональности или в том, как он заставляет нас заново посмотреть, где в действительности система стейблкоинов размещает наше доверие. #baby $BABY @BabylonLabs_io
Раньше я почти по умолчанию считал, что Биткоин действительно раскрывает свою роль только тогда, когда он находится вне любой логики DeFi. Чем меньше он зависит от других систем, тем лучше он сохраняет исходные предположения о безопасности. Я воспринимал это как естественное ограничение, а не как задачу, которую нужно решать.
Когда я читал материалы Babylon, один момент заставил меня довольно долго остановиться. Они не начинают с идеи переноса BTC в другую блокчейн-сеть. Вопрос, который они задают, звучит так: может ли Биткоин участвовать в приложениях DeFi, не полагаясь на мост (bridge) или на централизованную кастодиальную единицу. Это отличается от того, как я по-прежнему себе это представлял.
Сначала я думал, что Trustless Bitcoin Vault — это просто более тщательно спроектированный мост, а затем понял, что фокус не в том, чтобы перемещать активы. Мне пришлось перечитать раздел с дизайном несколько раз, прежде чем стало ясно: они пытаются сохранить модель доверия Биткоина неизменной, одновременно открывая возможность использования BTC как залогового актива. С моей текущей точки зрения, реальное отличие в том, что система старается сократить количество предположений, которые нужно закладывать на посредника, вместо того чтобы менять сам Биткоин.
Это заставило меня больше задуматься о философии дизайна. Возможно, Babylon не просто добавляет в DeFi новый primitive. Они пытаются переопределить, как в рамках одной системы разделяются право собственности, право использования и доверие.
Меня по-прежнему волнует вопрос, будет ли этот подход принят более широко: если он получит распространение, то самое большое изменение, скорее всего, произойдет либо в DeFi, либо в том, как мы вообще понимаем подключение Биткоина к DeFi, не теряя его ключевых базовых предпосылок. #baby $BABY @BabylonLabs_io
Раньше я часто думал, что если нужно встроить Bitcoin в более сложные системы, придется принять наличие посредника. Это может быть bridge, кастодиальная организация или группа подписантов, которые по очереди удерживают контроль.
Когда я читал материалы Babylon, один момент заставил меня притормозить. Они не начинают с расширения возможностей Bitcoin. Вместо этого они пытаются сохранить Bitcoin в рамках его собственной сети, при этом условия использования на будущее задаются еще с момента создания vault.
Сначала я полагал, что Trustless Bitcoin Vault — это просто модель блокировки BTC для целей staking. Затем я понял, что фокус в том, как с самого начала фиксируются допустимые расходные пути благодаря структуре Taproot и заранее подготовленным транзакциям, а не в передаче управленческих полномочий организации или группе людей. Мне пришлось перечитать раздел по архитектуре несколько раз, прежде чем стало ясно: Babylon не пытается сделать Bitcoin «умнее». Они просто стремятся сократить количество предположений, в которые вынужден верить пользователь. С моей нынешней точки зрения, примечательно даже не само устройство vault — примечательно то, как Babylon пересматривает trust model. В системе по-прежнему есть много участников, но эти роли не имеют кастодиального контроля над Bitcoin. Вместо того чтобы надеяться, что какая-то сторона всегда будет действовать правильно, пользователи полагаются в большей степени на заранее зафиксированные правила, которые исполняет сам Bitcoin.
Возможно, более уместный вопрос заключается в том, меняем ли мы распределение доверия, когда все полномочия привязаны к правилам с самого начала, или же мы по-новому определяем само значение фразы «не нужно доверять» в рамках системы. #baby $BABY @BabylonLabs_io
Как работает механизм Intent-based Execution в Newton Protocol?
Раньше я всегда по умолчанию считала, что блокчейн-транзакция действительно начинается только тогда, когда пользователь подписывает конкретную транзакцию; я видел(а) это естественной точкой отсчёта для любой системы. Пользователь точно решает, что будет выполнено. Система обязана лишь проверять и исполнять корректно то, что было подписано. Я почти никогда не задумывался(ась) о том, есть ли ещё способы разделения ответственности.
Раньше я по умолчанию считал, что для того, чтобы система могла подтверждать транзакции, прежде всего нужно иметь доступ ко всем необходимым данным. Это, казалось бы, очевидно. Чтобы проверить, верно утверждение или нет, кто-то должен иметь право на доступ к относящейся к делу информации.
Когда я внимательно прочитал документацию Newton Protocol, один момент заставил меня остановиться. Акцент дизайна не в том, чтобы подтверждать быстрее, а в том, как доказать, что условие выполнено, при этом ограничивая раскрытие чувствительных данных. Мне пришлось перечитать раздел про Verifiable Credentials, Zero Knowledge Proofs и архитектуру защиты данных несколько раз. Сначала я думал, что это просто способ усилить приватность, но затем понял, что смотрел на проблему слишком узко. С моей текущей точки зрения важно не то, где данные передаются или хранятся, а то, что система делится только тем, что действительно нужно для проверки. Подтверждающая сторона опирается на проверяемые доказательства или аттестации, а не на весь исходный массив данных.
Это также заставило меня пересмотреть trust model. Доверие больше не сосредоточено на том, одной стороне позволено видеть данные или нет; оно разделено между криптографическими доказательствами, сетью операторов и экономическими гарантиями протокола. Я все еще сомневаюсь, является ли самым большим изменением здесь именно технология или же то, как мы определяем, что считается достаточным, чтобы можно было доверять. #newt $NEWT @NewtonProtocol
Сегодня я прочитал объявление о Binance Wallet Booster от GRVT. Первое, что привлекло мое внимание, — это не 1,5 миллиона токенов, а строка «не нужно совершать сделки, не нужно пополнять активы». Сначала я подумал, что это просто довольно привычная кампания по онбордингу.
Но когда я снова открыл документ о Rewards Season 2, мне пришлось остановиться. Механизм распределения наград здесь привязан к действиям, которые засчитываются на платформе, таким как торговля, пополнение и поддержание активов на GRVT, участие в GRVT Strategies или другие формы вкладов. Такой подход довольно сильно отличается от варианта, когда нужно просто выполнить несколько задач, чтобы получить право на награду.
Тогда я только понял, что интересное не в двух отдельных программах, а в том, что они, похоже, закрывают два разных этапа в одном и том же пути пользователя. Одна сторона помогает пользователям получить доступ к экосистеме с очень низким порогом, а другая — побуждает их возвращаться и пользоваться возможностями платформы со временем.
Я все еще не считаю это противоречием: возможно, это просто две разные цели в рамках одной стратегии роста. Но что заставляет меня продолжать думать — после того как первоначальные стимулирующие программы завершатся, сколько людей все же продолжат использовать продукт именно из-за самого опыта, который он дает, а не только ради наград? #grvt @grvt_io
У меня есть привычка проверять табло отправлений перед тем, как выехать в аэропорт, затем снова проверять его в такси и еще раз после того, как я захожу в терминал. В большинстве случаев ничего не меняется. Номер выхода тот же. Время то же. Информация у меня уже была. Я просто не до конца доверяю этим сведениям, пока не наступает момент, когда они действительно нужны.
Это не давало мне покоя, пока я читал про токен-запуск GRVT 21 июля. TGE со стороны выглядит как единое событие — почти как будто кто-то щелкнул выключателем. Но чем больше я смотрел на процесс, тем меньше он напоминал это.
Токен становится по-настоящему значимым только потому, что целая серия решений уже зафиксирована до начала торгов. Объем предложения определен. Распределение заранее задано. Пользователи регистрируются для своего airdrop, выбирают, забрать сразу или отложить через механизм Multiplier — и эти решения становятся частью того состояния, которое система обязана соблюсти, когда $GRVT пойдет в live. Листинг не столько создает право собственности, сколько раскрывает право собственности, которое уже было учтено.
Изначально я думал, что самая сложная часть TGE — это управление рыночным спросом. Теперь я менее уверен. Рынки могут находить цены самостоятельно. Более трудная задача, возможно, состоит в том, чтобы гарантировать, что каждый баланс, каждое распределение и каждое требование (claim) разрешаются ровно так, как протокол обязался до того, как кто-либо начнет торги.
Я все еще думаю, является ли успешный TGE на самом деле запуском токена или доказательством того, что каждое сделанное до запуска допущение выдержит первую минуту после того, как все начнет работать. #grvt @grvt_io
Чем выполнение Intent в Newton Protocol отличается от традиционного вызова Smart Contract?
Раньше я обычно воспринимал вызов smart contract как нечто почти само собой разумеющееся. Если система должна сделать что-то, пользователь должен точно знать, какой contract нужно вызывать, какую функцию нужно выполнить и какие данные нужно передать. Я особо об этом не задумывался — это просто тот способ, которым блокчейн работает изо дня в день. Я привык видеть все onchain-взаимодействия как последовательность команд. Пользователь отдаёт указание, а машина выполняет именно его. Если нужно провести более сложную транзакцию, достаточно просто добавить больше вызовов contract, собрав их вместе. В моём представлении логика системы всегда начинается с вопроса: «Какой API вызывать?»
Раньше я по умолчанию считал, что ограничения Smart Contract в основном сводятся к выразительности логики. Если контракт достаточно сложный, написан достаточно строго и тщательно проверен аудитом, то практически любые правила можно вынести в блокчейн. Я довольно долго смотрел на проблему именно с этой точки зрения.
Когда я внимательно изучил документацию Newton Protocol, я наткнулся на одну деталь, из-за которой мне пришлось остановиться. Проект не пытается раздвигать границы Smart Contract, чтобы заставить его делать больше. Вместо этого он отделяет часть, которая принимает решения, от части, которая выполняет их. Сначала я думал, что это лишь способ организации архитектуры, но чем дальше я читал, тем больше понимал, что ошибался в фокусе.
С нынешней точки зрения, проблема не в том, что Smart Contract не хватает функциональности. Ему не хватает способности обрабатывать решения, зависящие от постоянно меняющегося контекста, при этом сохраняя границы, которые можно проверять. Smart Contract отлично исполняет то, что уже известно, но не предназначен для самостоятельной оценки вещей, которые проявляются только во время работы системы.
Это заставило меня пересмотреть модель распределения ответственности. Возможно, от Smart Contract никогда не ожидали, что он будет «хранилищем» всей логики; ему, скорее, следует быть местом, где подтверждается результат процесса принятия решений, который можно верифицировать.
Мне всё еще интересно, расширяет ли такой подход реальные возможности Smart Contract или же он на самом деле переопределяет роль, которую они должны были выполнять изначально. #newt $NEWT @NewtonProtocol