就像我在
之前的文章
中所说的，理解某种新事物的最好方式是将其与自己熟悉的东西作比较。
就我而言，我最熟悉的事情就是——在AWS上构建云应用程序。
DLT如何以及为何与传统云有所不同
对分布式数据库的内容达成共识并不是什么新鲜事。如果您使用AWS DynamoDB之类的云数据存储，那么它有可能运行共识协议，以便节点存储符合一致性的数据内容。
这些节点全部由提供商数据中心内运行的单独云服务商拥有和管理。共识协议只需要在这个受控环境下有效。
像区块链这样的分布式账本技术（DLTs）不能做出这些简化的假设。他们必须假设运行共识协议的节点分布在世界各地，运行在高度变化的硬件上，并通过不可靠的网络连接。他们还必须假设某些节点可能是恶意的，故意做出威胁其他节点的工作。
这就是DLT与其云提供商不同的根本原因。除了常见的共识挑战之外，他们还需要
拜占庭式容错（BFT）
。
你所熟悉的大多数口头术语，如区块链，DAG，51％攻击，PoW，PoS等等都与DLT如何实现BFT有关。
我们需要审视这些差异以了解相似之处。
DLT本质上是一个键值储存库
一旦剥离了对DLT进行更改并查看存储内容的方式，那么逻辑上仍然可以将其作为键值储存库（KVS）进行查看。在AWS世界中，DynamoDB就是一个例子。
等等！ 如果这种情况发生在区块链或是缠结的DAG上呢？
DLT的结构反映了如何对账本进行修改并达成一致。稍后我会仔细研究一下。
DLT和使用情况之间的键，值表示方式各不相同。
键
在比特币中，键将是交易哈希和未支出输出索引的组合。
在Iota中，键被称为地址，并从拥有该地址的私钥中派生出来。以太坊是相似的，但是由公钥派生而出。
在Iota地址中有81个字符[A-Z9]。 这意味着27⁸¹的可能值。 所以它是非常不流行的KVS。
值
在Iota中，这些值由以下部分组成：
账本如何变更并达成一致
那么我们如何改变存储的值，而不触碰我们的DLT KVS密钥？
这就是用到精巧结构和算法的地方。
节点并没有试图就我们的KVS键值和私钥达成一致。他们试图达成共识的只是共享账本中的条目。
完整的账本由交易构成，交易被描述成一个或多个密钥下所存储值的更改。
交易
例如，交易可能包含以下更改：
-
从地址abcdabcdabcdabcdabcd的余额中减去10 iotas ...
-
添加3 iotas到地址efghefghefghefghefghefgh 的余额...
-
添加7 iotas到地址ijklijklijklijklijklijkl 的余额中...
将交易添加到账本
区块链
在区块链中，用户不直接将交易添加到分类账，而由称为矿工的特殊节点完成。
用户将交易提交到交易池。矿工们选择其中一些添加到一个新的块。 如果您的交易具有足够的吸引力（费用方面），那么矿工可能优先打包发送你的交易。
在PoW协议中，矿工现在可以让一些具有足够强大算力的处理器计算哈希值。
一旦他们算出哈希，他们就会将这个块广播给其他节点和矿工。 此时，您的交易将附加到账本中（因为它所属的块已附加到父块）。请注意，由于尚未达成共识，因此尚未确认此交易即是该账本的一部分。
因此，交易不会连续添加，它们会作为块的一部分定期添加。大约每10分钟就会向比特币添加一个新块。
Iota 缠结
在Iota中，用户将他们的交易附加到分类账本身。他们随时都可以这样做。这意味着交易将不断添加到分类帐中。
这笔交易通过两个地方添加到账本中——即它引用验证的二笔近期的未确认交易（称为tip）。
当节点附加了该笔交易时，它将该交易广播给它所有的邻居节点。进而这些邻居将它继续广播给自己的邻居节点，直到交易传播到整个网络。
节点的邻居是存在于所有节点的一个小子集。每个节点通常与其他节点有一组完全不同的邻居，并自己保留这些信息。
理论上最完美的运行节拍是，当你的交易完成传播时，也正是其他节点开始将他们的交易引用验证到你这笔交易之时。
与将交易添加到区块链账本的有序单个文件进程相比，以下几点不同之处：
-
所有节点不断增加交易
-
它将连接到其他两笔交易
-
节点与节点的连接关系（网络拓扑）
-
以及交易的传播方式
使得Iota成为一个正向的混沌过程。
攻击iota不仅仅需要足够的哈希算力来产生比网络其他部分更多的交易，还需要尽快将这些交易传递到其他节点，以便他们优先将交易引用到您的交易之中。这意味着你需要很好地连接到其他节点，即需要很多邻居。
在今天的网络规模下，这并不难做到，这也正是目前需要COO的原因。但Iota拥有宏伟的野心。他们并不想仅仅扩展到Visa的交易速度，他们的野心比这一目标大了一个数量级。
Iota希望成为所有机器（以及像人类一样肉质的机器）使用的协议，以建立对数据的信任并交换价值（在无数的微小额度交易中）。
在账本中达成交易的共识
DLT有不同的方式来达成共识和不同的探索性方法来决定交易何时被确认。
在比特币中，最长的PoW链获胜，交易通常被认为在获得最长链的6个区块深度时得到确认。
在Iota中，交易被所有当前的tip引用（直接或间接）时，交易被确认。当然，在向账本添加交易的混沌过程中，每个节点可能对当前的多笔tips有不同的想法。节点多次运行算法以给出概率性答案。
事件驱动进程改变Iota的账本
如果我们想要触发进程改变iota账本中某些地址的储存值时，该怎么办？
在我们到解释该问题之前，让我们看一下典型的云例子。
下图显示了一个简单的（被认可的）AWS应用程序。它包括：
在这个例子中，两个Lambdas都是由我们KVS的变化所触发的。流程如下：
-
第一个Lambda在与键A相关联的值发生更改时触发
-
它执行一些进程并将键B的值设置为它确定的某个值
-
第二个Lambda在与键B相关联的值发生更改时触发
-
它依次设置键C的值
这种事件驱动的过程往往在我们的云世界中非常有用。
如果我们想要处理对某些Iota地址值变化的更改，我们可以按如下方式修改此架构：
或者，如果您想定制您的Iota节点，理论上可以使用DynamoDB作为节点的KVS。或者，您可以将其用作生成二级索引的一种方法，可以使查找速度更快。
有很多有用的东西可以用来处理IOTA的商品支付场景
注意：现在你可以用Iota来做这个。
Iota分类帐是由所有人共同拥有的全球分布式共享的账本技术。然而，进程完全是私人的。在示例中，您拥有两项Lambdas的代码，并且您信任AWS为您运行它们。
Qubic
如果我们想要在不需信任的云服务提供商环境下，处理一些公开化的进程，该如何操作呢？
我们希望将进程的输入和输出记录在Iota账本上。
除非我们有一些方法可以简单地确定输出是否只能通过执行我们的函数产生，然而事实上我们并没有办法相信代码运行正确并且结果被忠实记录。
我们可以多次运行它，并在结果达到足够的百分比时接受一个结果。
如果我们希望我们的函数能够在任何地方运行，而不仅仅是在AWS Lambda上运行，那么我们需要一种创建函数和支持协议的方法，以使它可以在任何地方运行。
这实质上是Qubic正在解决的问题。Qubic本质上是一个分布式的AWS Lambda的等价物。
Qubic协议的一部分是如何支付/激励运行代码的节点（称为Oracle机器），就像您向AWS付费一样。
就像你可以在AWS中做的事情比我更多一样，你也可以使用Qubic做很多的事情。
