#dusk $DUSK @Dusk Читать «Dusk Whitepaper», я обратил внимание на одну деталь, которую легко упустить: в описаниях разных контрактов используются разные времена.
Раздел 6.2, где описываются Genesis, Transfer и Stake Contracts, в основном говорит о том, какие функции они выполняют в настоящее время: переводы, удержание Gas, стейкинг и т. п. Это инфраструктура, необходимая для работы сети Dusk.
А в разделе 6.3, где представлены Zedger и Citadel, встречаются куда более выраженные формулировки с ориентацией на будущее, например «designed to be deployed» и «will allow».
Само по себе различие времен, конечно, не может доказать, что та или иная функция «еще не реализована». Но как сигнал технического документа это хотя бы напоминает: архитектурные замыслы в whitepaper’е, уже развернутые протоколы и реальные возможности продуктов, которые уже сейчас можно использовать, — это не одно и то же.
Теперь посмотрим на официальный сайт Dusk: статус разных продуктов уже помечен как Live, Building и Testnet. Это, наоборот, дает более конкретную систему отсчета. Когда мы обсуждаем ту или иную способность, стоит ли нам тоже различать: она задумана, уже развернута или уже реально проверяема и применима?
Сегодня обсуждение Dusk в контексте регулируемых финансов на блокчейне все больше концентрируется на полном процессе — от доступа инвесторов до контролируемых переводов, раскрытия информации о приватности и расчетов.
И тогда вопрос становится более конкретным:
Zedger, XSC, Citadel — на каком из этапов «дизайн, развертывание, проверяемое использование» они сейчас находятся?
Если цель Dusk — обеспечить реальные регулируемые финансовые рынки, то, переходя от дизайна в whitepaper’е к практическому использованию в реальном рынке, какой ключевой этап сейчас больше всего нуждается во внешней проверке? #dusk $DUSK @Dusk
Раздел 6.2, где описываются Genesis, Transfer и Stake Contracts, в основном говорит о том, какие функции они выполняют в настоящее время: переводы, удержание Gas, стейкинг и т. п. Это инфраструктура, необходимая для работы сети Dusk.
А в разделе 6.3, где представлены Zedger и Citadel, встречаются куда более выраженные формулировки с ориентацией на будущее, например «designed to be deployed» и «will allow».
Само по себе различие времен, конечно, не может доказать, что та или иная функция «еще не реализована». Но как сигнал технического документа это хотя бы напоминает: архитектурные замыслы в whitepaper’е, уже развернутые протоколы и реальные возможности продуктов, которые уже сейчас можно использовать, — это не одно и то же.
Теперь посмотрим на официальный сайт Dusk: статус разных продуктов уже помечен как Live, Building и Testnet. Это, наоборот, дает более конкретную систему отсчета. Когда мы обсуждаем ту или иную способность, стоит ли нам тоже различать: она задумана, уже развернута или уже реально проверяема и применима?
Сегодня обсуждение Dusk в контексте регулируемых финансов на блокчейне все больше концентрируется на полном процессе — от доступа инвесторов до контролируемых переводов, раскрытия информации о приватности и расчетов.
И тогда вопрос становится более конкретным:
Zedger, XSC, Citadel — на каком из этапов «дизайн, развертывание, проверяемое использование» они сейчас находятся?
Если цель Dusk — обеспечить реальные регулируемые финансовые рынки, то, переходя от дизайна в whitepaper’е к практическому использованию в реальном рынке, какой ключевой этап сейчас больше всего нуждается во внешней проверке? #dusk $DUSK @Dusk
