最近再重新学习区块链，突然觉得智能合约并不是以前所想象的那样，感觉上他在实际业务中的使用场景极度匮乏，特写下此文，作为抛砖之作，请诸位大拿轻拍给我解惑，谢谢。
6 y% @5 {# L. s( p0 K- V7 }* r5 H+ @
    我所理解的智能合约是什么! K, Y9 v2 ~1 G0 v  |" s
9 h' b+ C+ f) a- K
    记得刚接触区块链的时候，有次聚会，我是当面问VB本人，如果用智能合约来管理遗嘱执行，怎么做，实话说没听懂他的回复，当场有个兄弟给了个回复，“如果把区块链当作数据库的话，智能合约就是StoreProcedure或者Trigger”，最近多学了一点以后，深刻感觉到此言甚是。智能合约的使用要么是因为区块链上的什么数据出现变化，驱动了进行操作，要么是操作人进行操作，操作的结果仅是区块链上数据的变化。
7 e; A: c$ O2 l4 X9 q
; x' A: ~$ Q+ {1 b6 w    智能合约使用的局限性
+ |# t  a# N9 ?) e' ]0 F" d' t8 b' ?. F' t# X9 w4 M: F
    如上所述，智能合约的操作结果仅体现为区块链上数据的变化，那么独立使用智能合约的业务场景必须满足所有影响智能合约运行结果的数据必须存在于区块链上，并且智能合约的结果也仅能存在于区块链上。换言之操作智能合约的所有相关数据必须是在区块链上自适应的，智能合约本身并不访问、操作任何外部数据。
. C  W* p& q6 e9 A" L: Y. t# W) I. K: m0 `  v
    这样的应用场景在现实生活中很少，ICO代币发行就是这样一个应用场景，实话说这也是我现在能想到的唯一智能合约应用场景。
# G8 y# w3 q$ s# z5 M3 r
" W; K  Z* O# d3 z* ~% E; R    Oracle，TEE等概念的悖论' D5 i! x, [8 |/ \  E5 n

# X& q, d5 x9 Y7 C. }) u    按照以太坊的设计，是寄希望于Oracle来进行外部数据的导入，或者有人提出了所谓TEE（TrustableExecutionEnvironment）的概念，就是在以太坊虚拟机EVM之外的一个可信任的运行环境。这听起来是可以建立一个外部数据到智能合约的数据网关，但是客观上使用Oracle存在一个明显的悖论在于：
7 k( ?: H  x" g" L9 X& E- i" l  Y# g6 V5 K9 \
    Oracle的实现只能是中心化的应用，不可能DAPP来运行因此使用Oracle的假设前提是我们可以相信Oracle不会作恶，会提供并且能够对智能合约提供正确的数据信息那么悖论在于既然我们能够相信Oracle提供的数据，为什么不能够进一步相信Oracle来直接执行智能合约代码，得到计算结果后直接发送区块链上的交易，而不需要通过DAPP上的智能合约了？换言之看将智能合约的代码逻辑嵌入到Oracle所在的机器上执行。
7 J# b$ R2 V! F* J8 Y' \" y! w6 m' O8 Y! S' A" R3 d
    而这一点在实际应用中也有相当的优势，主要体现为：Oracle作为单机应用，如果用他来直接执行智能合约的代码，性能要比在区块链上执行性能要高很多，至少所有的应用都可以理解为一个独立的sharding，能够被智能合约所执行的需要消耗gas的逻辑计算在这个环境上执行几乎不会有任何代价；如果智能合约出现了问题，比如当年DAO的代码bug，如果是用部署在Oracle上的程序来进行操作，那么根本就不会是个问题；如果对于执行结果存在疑惑的话，所有相关方一样可以通过对于区块链上结果数据的审计来确认该程序是否按照约定的代码进行了转账操作
5 ?  \( R8 s) e) F+ X$ I9 g& n) L
    几个耳熟能详的智能合约例子在落地时的问题* N4 L  s& _9 y  S: A
. ^# ^4 i7 |1 _1 Y' E9 S
    一个针对会议的智能合约，通过它参会者可以买票，组织者可以设置参会人数上限，以及退款策略：这个使用场景看起来是DAPP了，他的潜在假设是组织者是诚实可靠的，当他收到了钱以后，会把票发出去；换个角度他解决不了组织者不诚实可靠的风险，而在前提假设成立的前提下，由组织者管理的中心化应用可能更有价值，如果担心组织者不可靠，完全可以要求组织者将数据保存到区块链上，由他人进行事后审计。关于对冲美元涨跌风险的智能合约，这个在实际使用中的问题在于，他需要一个信息采集器（Oracle），按照计划采集当前汇率，并更新到合约上，来驱动合约操作。这个的风险在于如果这个信息采集器在采集中出现一点问题，比如采集了一个错误的汇率，那么这个错误的汇率直接驱动了智能合约重新进行了余额分配，这时候再发现采集出错，那么从业务方案来说基本上是无计可施。当然如果最开始在合约中定义了rollback操作函数，那么为啥要用这个智能合约了？
+ J$ {8 B' T6 y- Z/ w3 @4 V$ g, \, O- Y8 G/ l2 t3 d
    可能的智能合约的发展未来* T, h1 C6 p4 J1 f, m8 C" J
) o' \0 \3 S3 d+ }
    简单想想，最近炒的较热的跨链技术可能是个智能合约发展的方向，如果所有客观现实的数据都能够在区块链上获取，那么智能合约也许可以通过跨链技术来访问其它链上的数据，来驱动业务的发展。假设所有的外汇兑换业务都通过一条区块链来完成，那么这条区块链上势必存在最新的汇率数据，那么通过跨链技术获得这个最新的汇率数据来驱动当前对冲美元智能合约的运行，可能会是个实际可落地的业务场景。  @' A1 |" P: l+ G
# p6 f* i. ?) A  D
    当然在实际运行中存在的问题是：. {1 `$ @, \3 ]9 ]5 ?7 x2 [
1 {9 _7 y( _" }* A. y; k* a0 o6 V! c5 i
    区块链本身存在的容量、性能瓶颈，使诸如外汇兑换业务这种具体业务全部上链的技术可能性在当前微乎其微即使技术可行，业务上这种具体业务要想完成完全的技术改造也不是一年两年的事情从区块链角度来看，跨链实际上隐含的假设还是相信另外一个信息系统的数据，本质上还是TEE的方案,只是这个TEE执行在区块链之上而已。后面的问题就是这个外部区块链被51%攻击了数据被篡改了怎么办？
  D1 T$ r) K5 m! @( M, _$ ~3 T6 V9 b( P8 D" F# I5 x
    当然实现这种跨链以后，想象空间就大很多，外汇兑换业务在当前是不可能，是不是能够做点别的，这个是存在想象空间的。
6 D2 q& X- [5 G: y: b" U6 f' U; D
: M5 \2 ?. F( t' s. {  {* u    总而言之，就我看，只要智能合约的执行结果需要involve到其它业务系统，或者人的操作，那么DAPP所带来的分散式、可信任就沦为空话，单点的不可靠反而会因为智能合约的固化造成问题的衍生、扩大。