На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
11 Лайков
Награда
11
6
Репост
Поделиться
комментарий
0/400
SerRugResistant
· 15ч назад
Проще говоря, это древний компромисс между безопасностью и свободой, ничего нового.
Посмотреть ОригиналОтветить0
GasWrangler
· 15ч назад
Технически говоря, ограниченная полнота Тьюринга на самом деле — это всего лишь театрализованная безопасность, маскирующаяся под инновации... если проанализировать данные, системы на основе аккаунтов — это просто обмен гибкостью на выполнение требований соответствия. На мой взгляд, это субоптимальный компромисс.
Посмотреть ОригиналОтветить0
GlueGuy
· 16ч назад
Опять началась гонка за полную тьюринг-полноту, по сути — один хочет свободы, другой — регулирования.
Посмотреть ОригиналОтветить0
PerpetualLonger
· 16ч назад
Братан, как только ты это сказал, я понял. Ограниченная тьюринг-полнота по сути — это как цепляющийся кода на блокчейне финансовой системы, которая накладывает ограничения. Общие блокчейны свободны, но риск взрывается; система аккаунтов безопасна, но ограничена в возможностях. Сейчас у меня полностью в позиции контракты на публичных блокчейнах — это ставка на то, что эта волна полностью прорвёт регулирование, вера.
Посмотреть ОригиналОтветить0
SighingCashier
· 16ч назад
Ха, снова старая тема о полноте Тьюринга, тут я накладываю на себя ограничения
Ограничения — ограничения, ну и ладно, по крайней мере, я могу спокойно спать, не беспокоясь каждый день о взрыве контракта
Посмотреть ОригиналОтветить0
MetamaskMechanic
· 16ч назад
Тьюринг-полнота была урезана, и это цена централизации
Система аккаунтов и смарт-контракты vs публичные блокчейн-контракты: технический баланс полноты Тьюринга
【区块律动】有个技术人士分享了个有意思的话题——账户体系下的智能合约到底和公链智能合约差在哪。
说白了,两者本质都是一回事儿:条件触发后自动执行的代码。但这里头有个关键区别,就是完全图灵完备性的问题。
公链上那些智能合约(比如Solidity写的),是完全图灵完备的,啥都能干。但账户体系这边的智能合约不同——它属于受限图灵完备。怎么受限呢?编程被严格卡在了一堆许可的模板脚本范围内,只支持那些预先设定好的、比较简单的条件触发功能。
为啥要这样设计?安全考虑,风控考虑。这套框架需要在金融体系的管控范围内运作,不能像公链那样野生野长。
有意思的是,从纯技术角度讲,用Solidity这样的完全图灵完备语言来开发这些合约根本不是难题——多种编程语言都支持。但真正卡住的地方在别的:怎么设计出一套让整个金融体系都能接受的标准接入规范和审计机制。这才是核心挑战所在。
说来说去,技术框架早就有了,关键还是在于制度设计和风险管控的平衡。