【区块律动】有个技术人士分享了个有意思的话题——账户体系下的智能合约到底和公链智能合约差在哪。说白了,两者本质都是一回事儿:条件触发后自动执行的代码。但这里头有个关键区别,就是**完全图灵完备性**的问题。公链上那些智能合约(比如Solidity写的),是完全图灵完备的,啥都能干。但账户体系这边的智能合约不同——它属于**受限图灵完备**。怎么受限呢?编程被严格卡在了一堆许可的模板脚本范围内,只支持那些预先设定好的、比较简单的条件触发功能。为啥要这样设计?安全考虑,风控考虑。这套框架需要在金融体系的管控范围内运作,不能像公链那样野生野长。有意思的是,从纯技术角度讲,用Solidity这样的完全图灵完备语言来开发这些合约根本不是难题——多种编程语言都支持。但真正卡住的地方在别的:**怎么设计出一套让整个金融体系都能接受的标准接入规范和审计机制**。这才是核心挑战所在。说来说去,技术框架早就有了,关键还是在于制度设计和风险管控的平衡。
アカウントシステムスマートコントラクト vs パブリックチェーンコントラクト:チューリング完全性の技術的トレードオフ
【区块律动】有个技术人士分享了个有意思的话题——账户体系下的智能合约到底和公链智能合约差在哪。
说白了,两者本质都是一回事儿:条件触发后自动执行的代码。但这里头有个关键区别,就是完全图灵完备性的问题。
公链上那些智能合约(比如Solidity写的),是完全图灵完备的,啥都能干。但账户体系这边的智能合约不同——它属于受限图灵完备。怎么受限呢?编程被严格卡在了一堆许可的模板脚本范围内,只支持那些预先设定好的、比较简单的条件触发功能。
为啥要这样设计?安全考虑,风控考虑。这套框架需要在金融体系的管控范围内运作,不能像公链那样野生野长。
有意思的是,从纯技术角度讲,用Solidity这样的完全图灵完备语言来开发这些合约根本不是难题——多种编程语言都支持。但真正卡住的地方在别的:怎么设计出一套让整个金融体系都能接受的标准接入规范和审计机制。这才是核心挑战所在。
说来说去,技术框架早就有了,关键还是在于制度设计和风险管控的平衡。