今年（2021）9/12 这一天 Cardano 迎来了一次对于 Cardano 来说史上最大的更新 Alonzo，支持智能合约并推出 Plutus 等一些列用于在 Cardano 上开发智能合约的工具，当然了，在此之前，Alonzo Testnet 早已经于 5/21 上线进行测试。作为市值前五十的链之一，如此重大的利好怎能不吸引来一群认为是发现了财富密码的开发者呢，因此 Cardano 社区并不缺少先锋
大部分程序员更熟悉的都是类 Ethereum account model 这样的编程模型，而 Cardano 采用的是一种受 UTXO 启发的 EUTXO(Extended Unspend Output Transaction) ，虽然大抵都知道 BTC 的 UTXO 概念，但估计没有多少人想象过 general UTXO 的模型是怎样的。
Cardano 本身出于对形式化验证的信念，选择的开发语言是 Haskell，并且提供的工具基本上也都是基于 Haskell 的。这边顺便提一下 Haskell ，虽然 Haskell 可能不算一门小众语言，甚至绝大部分程序员都知道这门语言，但 Haskell 的门槛极高，程序员们大都不会直接使用这门语言用于日常的产出，知道 Haskell 语言大都由于其浓厚学术背景为其他语言设计带来启发性思考。
EUTXO + Haskell + Plutus = 难上加难，这是摸着比黑更黑的夜在往前爬
这种地狱难度的开局，如果开荒连个教程都没有，那怎能行呢？在 release Plutus 的同时（其实要甚至更早），其实是附带了一个为期十周的先锋课程 input-output-hk/plutus-pioneer-program (github.com)，从理论到实践系统性的介绍了 Plutus 全家桶如何使用。这边我们直接快进到最后一课 Lecture 10，是一个使用 Plutus 实现 Uniswap 的例子，这可是当下让在去中心化世界让 token 流通起来至关重要的一项设施，我们看到 DeFi 这个词，甚至狭义的解释就是 Uniswap。
这里我们简单地看一下先锋课程中，基于 EUTXO 编程模型的 Uniswap 是如何设计的
很快啊，这边的快要结合 Plutus + EUTXO + Haskell 来看，Cardano 迎来了测试网上的第一个 DeFi 项目 Minswap，喜大普奔（甚至还有 400+ Retweet 和 800+ Like），毕竟是第一个 DeFi 项目，虽然只是测试网，还是吸引来了不少用户。
但有不少用户发现在使用 Minswap 时，不断地弹窗提示 “Transaction fail: UTxOs are being used this block. Please wait 20-40 seconds and try again.” 这导致 Minswap 的 UI 在测试网上不断地提示需要等待。于是便有用户非常困惑，在推特上质疑起 Minswap，甚至直接质疑到 Cardano 的可用性。在"理解万岁"的包容下，此时推特下得到的回复也大都是 Minswap 目前只是 Testnet ，出现这样的情况问题不大。甚至这些回复都不是来自 Minswap 的而是来自 Cardano 的粉丝。
这里顺嘴一提，如果感兴趣的话，可以加入到 Cardano 社群，不难发现 Cardano 的持有者们十分坚定，有些管理较为严格的社区，甚至有“空狗秒踢”的规矩。当然了，坚定并不意味着严肃，其中不乏乐子人，对于 Minswap 不能用回复还是比较有趣
在这之后，可能感觉推特的战火不够旺，有用户把战场转移到了 reddit 上，并且用了一个震惊体标题发了一个帖子Cardano smart contracts unusable for DeFi : CryptoCurrency (reddit.com)，这下直接把关注度一下子拉高了起来
还记得我们刚才提到的吗，Cardano 的信仰者大都十分坚定，发这篇帖子的作者马上就有很多人 PM 他为他送上来自美好世界的祝福。
出现“一个区块只能有一笔成交的交易”这个现象，其实跟 Minswap 设计有直接关系。我们知道，UTXO 在交易时，其实是消费掉上一个 UTXO 之后再生产一个新的 UTXO，也就是说，一个区块里只能对一个 UTXO 消费一次
根据 Minswap 的设计，程序的状态存储在一个 UTXO 中（下图的 SCn 指代 Smart Contract State i）而每一次的操作，无论是 liquidity/swap 操作都需要进行一次状态改变，每一次改变都会消费掉这个存储状态的 UTXO ，这便导致了 “Cardano has whitch only allow 1 transaction to process per block” 的认知，但这下罪名可就大了，直接对 Cardano 本身的设计产生了质疑
虽然已经有大量的 Cardano 粉丝对 concurrency issue 从技术上给出各种解释，但由于关注者众多，这个时候 IOHK（Cardano 的技术提供方）坐不住了，还是得亲自下战场参加战斗。
Cardano 创始人之一 Charles Hoskinson（国内一般称呼他为老查） 也以直播的形式加入战场，解释了 UTXO 与 Account 编程模型有着本质的不同，不是说 Cardano 不能并发，而是并发不能直接发生在一个区块里的一个合约（UTXO）上。而且实际上甚至一个 UTXO 就是就能有一个并行（parallelization EUTXO inherits per branch design），这是比 Ethereum 更加先进的方式
“你想用 Ethereum 的剑来斩 Cardano 的题，这不是我有问题，这是你有问题啊兄弟，拽着个锤子看到啥都像钉子”
并且 IOHK 的官网 BLOG 也发了一篇文章 Concurrency and all that: Cardano smart contracts and the eUTXO model - IOHK Blog，这篇文章从个方面回应了这部分对 Cardano 的质疑
DApps built on Cardano are not limited to one transaction per block. In fact, the block budget allows the execution of hundreds of simple transactions and several complex scripts
Our education team has previously shared a simple AMM-style DEX implementation in the Plutus Pioneer course. While this is useful for teaching purposes, this architecture would not directly support a commercial DEX where an order book approach and additional concurrency are required. A developer looking to deploy on the Cardano mainnet would need to improve the scalability of the architecture accordingly.
Developers need to write code in a way that severely restricts the opportunities for contention (e.g., by avoiding shared states and accidental dependencies). The system must then translate this concurrency into parallelism. Simply transplanting lessons learned on one blockchain will not work; while the learning curve is a little steeper, the results make this worthwhile. DApps should split up their on-chain state across many UTXOs. This will increase the concurrency in their application, thereby allowing higher throughput.
老查的直播中提到一篇文章，介绍了在 general UTXO 中如何处理并发问题，这篇文章主要提出了解决 UTXO 并发问题的大致框架，核心思想是 batching，当场景会发生 UTXO congestion 的时候，将多个 UTXO 在一个交易内处理完。
这个方案将问题处理分为三点，这三点并不是相互互斥的，具体的问题可以使用其中一点或者全部使用
- 将状态拆分，打个比方，比如做一个 Oracle 服务，我们可以不是只生产一个当前 oracle 状态的 UTXO，而是生成若干个
- 批处理，把需要共享的状态与需要依赖该状态的 UTXO 在一个交易内进行处理
- 懒更新，只有在需要该状态的时候才对这个状态进行更新，有个例子是，比如治理服务的投票统计，我们完全可以等到需要确定治理结果时，再对治理票数进行统计，而不是一有票就统计，这还能省下珍贵的链上计算资源
虽然看上去能解决问题，但其实也仅是个框架而已，真正落实到业务上还有许许多多需要处理的棘手问题，比如如何解决 batching executor 的 MEV 问题，给你全挂卖单把价格推高，自己插个交易把推高后的价格卖给你。怎么解决低成本的拒绝服务攻击，比如 state UTXO 如果被不进行服务的有恶意的竞争对手占着该怎么办呢？是不是需要再加上治理层，治理层的 shared state 有没有可能又需要治理治理层的套娃设计？因此，最终的协议可能要比目前的 DEX 要复杂不少，再加上熟悉 Haskell 的人应该不多，从协议到实现便需要花费更多的时间去落实到工程实现上。
还是 mask45 这位兄弟，这两天又发了个帖子 It’s been over 11 weeks and there are still no Cardano dapps : CryptoCurrency (reddit.com)，大概内容就是感谢 PM 里来自美好世界的祝福，嘲讽了下各种 upcoming dapps 至今还没有影子，并发问题是否真的解决了？
有些看起来比较中肯的声音，Cardano 的合约开发起来比其他竞争对手要复杂 100x，这是需要时间去解决的，也有比较激进的人认为用 Haskell 进行合约开发是愚蠢的
“第一次，有了智能合约，也迎来了历史高点，两份喜悦相互重叠，这双重的喜悦又带来了更多更多的喜悦。本应已经得到了梦幻一般的幸福时光，然而，为什么，会变成这样”。很显然，现在显然是一个快节奏的的版本，大部分人已经习惯这种三天开发一个 XSwap，一周开发一条 X 智能链，像 Cardano 这种后期可能才能发力的真的不讨喜