Смарт-контракты стали для разработчиков воротами для создания разнообразных и быстрорастущих приложений. Однако изначально смарт-контракт был разработан как инструмент блокчейна, позволяющий программам, хранящимся на блокчейне, выполняться при соблюдении определенных условий на цепи. Это приводит к важной проблеме смарт-контрактов - они строятся на основе и, следовательно, наследуют все неэффективности и проблемы цепей, на которых размещаются.
Невозможно исправить - Например, блокчейн - это неизменяемая бухгалтерская книга, в которую можно заносить только данные, и контракты в ней создаются по тому же принципу. Хотя такая конструкция может быть приемлемой для очень специфических случаев использования, со временем она доказала, что является существенным недостатком конструкции. В качестве примера можно привести взлом кошелька Parity в 2017 году. Parity - это компания по разработке программного обеспечения для кошельков, созданная сооснователем Ethereum Гэвином Андресеном. Несмотря на практически неограниченный опыт и ресурсы, Parity поставлялась с ошибкой, которую в итоге использовал хакер, фактически лишив все мультисиговые кошельки на платформе возможности совершать транзакции, заблокировав перевод более ста тысяч ETH. В редактируемом и обновляемом контракте эта проблема была бы решена и исправлена в течение нескольких минут.
Дорого выполнять - С течением времени популярность криптовалютной индустрии вызвала появление новых инноваций, которые проверили пределы текущих технологий смарт-контрактов. В таких блокчейнах, как Ethereum, комиссия за транзакцию зависит от размера самого смарт-контракта, то есть более сложные контракты, такие как контракты майнинга NFT, стоят дороже. По мере увеличения количества и сложности контрактов в каждом приложении росли и операционные расходы. Не все смарт-контракты так дороги, как другие. Контракты, выполняемые на BNB Smart Chain, на порядок дешевле в сравнении с Ethereum, несмотря на то, что являются монологом EVM. Но BNB Smart Chain отказывается от распределения и децентрализации, чтобы достичь этого, и работает на гораздо меньшем объеме. Solana еще на порядок дешевле в эксплуатации, однако искусственно заниженные комиссии за транзакции привели к перегрузкам, вызванным ботами, что привело к сбоям в работе.
Неспособность к масштабированию - Дебаты о масштабировании часто плохо понимаются разработчиками. Некоторые указывают на высокую пропускную способность транзакций Solana как на доказательство того, что цепочки могут быть построены для масштабирования. Но нужно понимать, что масштабируемость находится в обратной зависимости от необходимости публичной модели, не требующей доверия и управляемой консенсусом. Непубличные бухгалтерские книги, работающие на основе централизованных баз данных, например, тех, что обслуживают компании, выпускающие кредитные карты, могут масштабироваться без проблем, поскольку они не полагаются на громоздкий и неэффективный механизм консенсуса и не нуждаются в неизменяемой бухгалтерской книге, которую может проверять общественность. Несмотря на то что Solana может обрабатывать больше транзакций и быстрее, чем большинство публичных цепочек, у нее есть свои проблемы, которые связаны с компромиссами в дизайне для достижения этой цели. Смарт-контракты, созданные на основе существующих публичных блокчейнов, просто не могут в достаточной степени соответствовать потребностям всех приложений, особенно тех, которые связаны с большим количеством транзакций, таких как глобальные платежные шлюзы. Таким образом, они в конечном итоге ограничены в своих возможностях, что ставит разработчиков в затруднительное положение.
Сложность изучения - В настоящее время не существует языкового стандарта, на котором разрабатываются и создаются смарт-контракты. В результате в отрасли преобладает фрагментация, что еще больше усложняет и без того непростую задачу освоения совершенно новой парадигмы разработки. Разработчики, создающие код смарт-контрактов на Ethereum, заметят, что базовым языком является Solidity, стандарт кодирования, похожий на Javascript. Но те, кто создает программные библиотеки на Solana, должны владеть Rust, совершенно другим языком, а разработчики, экспериментирующие со смарт-контрактами на Cardano (одна из крупнейших цепочек с поддержкой контрактов по рыночной стоимости), должны знать Haskell, редко используемый язык разработки. Поскольку публичная база знаний о Solidity настолько обширна, разработчики естественным образом тяготеют к обучению построению на виртуальной машине Ethereum (EVM), зачастую не зная, насколько уязвимы такие контракты для эксплойтов, насколько дорогостоящими могут быть неэффективные контракты и каковы конечные ограничения смарт-контрактов для большинства приложений.
Хотя замысел смарт-контракта вполне оправдан, он был разработан для определенной цели, однако с учетом сегодняшнего разнообразия приложений и сценариев использования оригинальная архитектура просто не подходит для текущих потребностей, не говоря уже о следующем поколении приложений и технологий блокчейн.
Полное содержание документации по Dark Fusion - ПЕРЕЙТИ