图论 物联网_智慧广电物联网+区块链 交易与支付

智慧广电物联网+区块链  交易与支付

交易

交易被视为一种消息，支持多类型的个0.3807615412035146可0.3807615412035146组合成一个数据块 ，该称作一个单元 (Unit )，单元与之间相互链接组合成一个DAG 图。由于单元可以链接到任意一个或多之前的单元，不需要为共识问题付出更多的计算成本和时间，也不必等待节点之间数据强同步，甚至没有多个数据单元拼装区块的概念，因此可以极大提高交易并发量，确认时间也可以最小。

单元结构

单元包含有：

l version(版本)是协议版本号。将根据这个版本的协议解释该单元；

l  alt是替代货币的标识符，稍后我们将会讨论;

l  messages(消息)是包含实际数据的一个或多个消息的数组;

o    app是一种信息类型，比如说“payment”代表支付，“text”代表任意文本信息等等

o    payload_location说明在哪里找到消息的有效载荷。如果有效载荷包括在消息中，则可以是“内联”，如果在互联网地址可用有效载荷，则是“uri”，如果未发布有效载荷，则是“无”，被私有地存储和/或共享，并且payload_hash 用于证明它存在于特定的时间；

o    payload_hash是base64编码中的有效载荷散列;

o    payload就是真实的荷载量(因为这是这个例子里的“内联”)。有效载荷结构是特定的应用程序。付款描述如下：

n   输入代表了一串由支付(指令)消耗的输入货币。输入货币所有者必须在单元的签名者(作者)之中;

•       单元是指生产货币的哈希单元。单元必须计入在最后一个球的单元才可消费;

•       message_index(消息索引)是输入单元的消息数组的索引。它表明生产货币的消息;

•       output_index是指进入输入单元message_index消息的输出数组的索引。它表示货币产生的输出;

n  输出是一组输出，表明谁收到钱；

•       address(地址)是指收件人的Byteball地址;

•       金额是他收到的金额;

l  作者是指创建和签署本单元的作者数组。所有输入货币必须属于作者;

o    地址是作者的Byteball地址;

o    认证是证明作者真实性的数据结构。最常见的是ECDSA(椭圆曲线数字签名算法)签名;

l  parent_units是父母单元的散列数组。它必须按照字母顺序排列;

l  last_ball和last_ball_unit分别是最后一个球及其单元的哈希值。

l witness_list_unit是可以找到见证列表的单元的哈希值。

所有哈希值都采用base64编码。

数字资产

DAG本质上是基于DAG的分布式数据库，数据状态一旦确定则不可逆转。在各种类型的数据中，具有社会普遍意义的数据是比较有价值的，比如个人资产数据。在Byteball中，资产可以发布、转移以及交换，类似于Byteball的基本货币bytes。资产可以代表任何有价值的东西，比如债务、股票、会员积分、通话时间、商品、其它加密货币等。

在定义新资产时，可以设置以下属性：

l cap：资产总量，比如bytes的总量为1015

l  is_private：资产转移是否公开，比如bytes为公开

l  is_transferrable：资产是否可以在无发行方允许的条件下进行流通，如果不可流通，则资产的收发方中必须有发行方，比如bytes为可流通

l  auto_destroy：资产在发送回发行方时是否自动销毁，比如bytes为不自动销毁

l  fixed_denominations：资产是否以固定面额进行流通(类似纸币)，比如bytes可以以任意金额流通

l  issued_by_definer_only：资产是否仅由发行方发布，比如bytes均在创世单元中发布

l  cosigned_by_definer：资产在每次转移时是否必须由发行方共同签名，比如bytes是不需要的

l  spender_attested：资产在使用时用户是否需要通过认证，比如bytes是不需要的

l  attestors：受资产发行方认可的认证地址，可以在后续过程中修改

l  denominations：如果资产具有固定面额，定义面额种类以及各类别总量

l  transfer_condition：资产转移需要的额外条件，语法与地址定义脚本相同(除了不使用sig之外)

l issue_condition：资产发布需要的额外条件

在定义资产时，每个单元中最多只能有一条asset消息。当资产定义单元发布后，后续都通过引用该单元的hash来引用该资产。资产只能定义一次，除了attestors之外均不能进行修改。资产定义的解释权在发行方，其具体含义由其进行解释。资产定义中的不同属性的组合可以适用不同的场景。

总量有限的资产必须在一个交易中全部发布，比如，所有的bytes都是在创世单元中发布的。如果资产总量有限，发布时serial_number必须为1；如果资产总量不受限，每次发布时serial_number必须保证不同。

隐私资产

公开资产在转移过程中，其内容在交易中是完全公开的。而对于隐私财产，在转移时，仅发送特定时间点资产转移的证据；同时，发送者通过私有通道把资产发送给接收者；接收者可以通过区块链上的资产转移证据来验证是否得到该笔资产。

为了解决双花问题，需要在单元增加新的字段spend_proof，要求：

l 它仅依赖于其所花费的输出，相同的输出将产生相同的spend_proof

l 无法通过它逆向推断出所花费输出的任何信息

在发行隐私资产时，由于需要公开表明已发行该资产，因此不需要添加扰乱因子。在资产传递过程中，发送者已知扰乱因子，虽然他可以知道接收者是否花费了这笔资产，但是他无法知道这笔资产的下一个接收者是谁，也就无法继续跟踪该笔资产的进一步流向了。

数据

结构化数据(数据库)

当用户想要向数据库添加数据时，他创建一个新的存储单元并将其广播给他的对等节点。存储单元(除了别的以外)还包括：

l  要存储的数据。一个单元可以包括多个数据包，称之为信息。有许多不同类型的信息，且各有自己的结构。其中一种信息类型是支付，用于向对等节点发送bytes(字节币)或其他资产。

l  创建单元的一个或多个用户的签名。用户由其地址标识。个人用户可以(并且鼓励)拥有多个地址，就像比特币。最简单的情况，地址源于公钥，再次类似于比特币。

l  引用由其哈希值标识的一个或多个先前的单元(父母单元)。

引用父母单元是建立单元的次序(目前为止只有部分次序)和推广区块链结构。由于我们不局限于连续块之间的单亲 - 单子关系，所以我们不必争取近同步(性)，并且可以安全地承受大的延迟和高吞吐量：每个单元只会有更多的父母单元和更多的子单元。如果我们沿着父子链在历史上前进，当同一单元被多个后来的单元引用时，我们将观察到许多分叉，并且当同一单元引用多个较早单元时，许多单元逐渐融合(开发者已经习惯看到这个动态)。这种结构在图论中称为有向无环图(DAG)。单位是顶点，父子链是图的边缘。

非结构化数据(文本)

运行“text”消息类型可以存储任意文本。

unit: { ... messages: [ ... { app:  "text", payload_location:  "inline", payload_hash:  "hash of payload", payload:  "any text" }, ... ], ... }

对文本的解释取决于作者和需要查看数据的合作伙伴，MitTrust节点除了检查它是一个字符串以外，并不验证它。可以使用此消息的类型，例如，发送不可信的微博。有效载荷可以是私有的，并且是有用的，例如，用于存储用户的知识产权的哈希，或用于存储仅少数方需要知道的合同文本的哈希。

文件数据(简表)

如果用户愿意，可以在MitTrust存储他们的文件。他们用这样的一个信息：

unit: { ... messages: [ ... { app:  "attestation", payload_location:  "inline", payload_hash:  "hash of payload", payload: { address:  "ADDRESS OF THE SUBJECT" profile: { name:  "Joe Average", emails:  ["joe@example.com"] } } }, ... ], ... }

他们透露，自己的数据量和真实性都依赖于用户自己。为了保证任何特别有关用户的信息是真实，系统必须寻找证据来证明。

地址

地址定义

DAG中用户使用地址进行收发交易。地址本质上对应的是一段具有特定含义的脚本，该脚本称为地址的定义。任何能够使地址定义脚本输出为真(也称作解锁该脚本)的人具有使用该地址资产的权限。与Bitcoin类似，最常用的地址定义脚本是公钥(采用BASE64编码)，即具有相应私钥的人可以使用该地址的资产，比如

["sig",{"pubkey":"Ald9tkgiUZQQ1djpZgv2ez7xf1ZvYAsTLhudhvn0931w"}]

对于地址定义脚本进行哈希，再加上校验位就得到了地址，Byteball的地址采用BASE32编码。DAG地址的校验位并不是全部放在尾部，而是穿插着放在哈希值中间，防止有攻击者在地址中间进行恶意修改。

按照此流程，上面公钥脚本对应的地址为：

A2WWHN7755YZVMXCBLMFWRSLKSZJN3FU

如果地址仅用于接收交易，其定义脚本可以不对外公布。但是当用户首次使用该地址进行发送交易时，他需要在发送的单元中声明该地址的定义脚本，比如

unit: {   ...   authors: [ {     address:  'DJ6LV5GPCLMGRW7ZB55IVGJRPDJPOQU6',     definition: [       "sig",  {"pubkey":"AsnvZ3w7N1lZGJ+P+bDZU0DgOwJcGJ51bjsWpEqfqBg6"}     ],     authentifiers: {       r:  '3eQPIFiPVLRwBwEzxUR5thqn+zlFfLXUrzAmgemAqOk35UvDpa4h79Fd6TbPbGfb8VMiJzqdNGHCKyAjl786mw=='     }   } ],   ... }

其中，authentifiers是用户采用私钥对除authentifiers之外的数据进行的签名。在用户使用该地址首次发送单元之后，它不允许再发送地址的定义。当然，只有在该地址的第一个单元到达稳定后，用户才可以发送后续单元。

用户可以在保持地址不变的条件下修改地址的定义脚本，用户需要发送消息

unit: {   ...   messages: [     ...     {       app:  "address_definition_change",       definition_chash: "I4Z7KFNIYTPHPJ5CA5OFC273JQFSZPOX"     },     ...   ],   ... }

definition_chash为新的地址定义脚本生成的地址。那么，下一个从原地址发出的单元有以下两条要求：

1.     必须把address_definition_change这个单元作为其last_ball；

2.     在修改地址定义脚本后发出第一个单元时，需要把新的定义脚本作为第一条message。

显然，新的地址定义脚本生成的地址跟原地址是不相同的。当用户迁移到新的设备上，同时想保持地址不变时，可以使用这种方式来修改地址定义脚本。

地址定义脚本中必须显式地(使用sig)或隐式地(使用address)包含至少一个sig。为了防止消耗过量的资源，脚本的操作总数限制在100以内，包括授权地址及脚本模板中的所有操作。

逻辑运算符

定义可以包括“and”条件，例如：

["and",  [ ["sig",  {pubkey: "one pubkey in base64"}], ["sig",  {pubkey: "another pubkey in base64"}] ]]

为了签名交易，例如，手提电脑和智能手机需要来自两个独立设备的签名时，这是有用的。

“或”条件，如：

["or",  [ ["sig",  {pubkey: "laptop pubkey"}], ["sig",  {pubkey: "smartphone pubkey"}], ["sig",  {pubkey: "tablet pubkey"}] ]]

当用户想要从他的任何设备使用相同的地址时都很有用。

条件可以嵌套：

["and",  [ ["or",  [ ["sig",  {pubkey: "laptop pubkey"}], ["sig",  {pubkey: "tablet pubkey"}] ]], ["sig",  {pubkey: "smartphone pubkey"}] ]]

定义可以要求最小数量的条件成为一个真的更大的集合，如2-of-3签名

["r of set", { required: 2, set: [ ["sig", {pubkey: "laptop pubkey"}], ["sig", {pubkey: "smartphone pubkey"}], ["sig", {pubkey: "tablet pubkey"}] ] }]

(“r”代表“需要”)，其特征在于两个强制签名的安全性和可靠性，因此在其中一个私钥丢失的情况下，地址仍然可用，并且可以用于改变其定义和用新私钥替换丢失的第三个私钥。

此外，不同的条件可以给予不同的权重，这是最低的要求：

["weighted  and", { required: 50, set: [ {weight: 40,  value: ["sig", {pubkey: "CEO pubkey"}] }, {weight: 20,  value: ["sig", {pubkey: "COO pubkey"}] }, {weight: 20,  value: ["sig", {pubkey: "CFO pubkey"}] }, {weight: 20,  value: ["sig", {pubkey: "CTO pubkey"}] } ] }]

佣金

如前所述，存储单元的成本是以字节大小为单位的。该佣金分为两部分：标头佣金和有效载荷佣金。有效载荷佣金等同于消息的大小; 标头佣金是其他一切的大小。两种类型的佣金是不同的分配。

标头佣金转到其中一个将付款人单元作为父母的未来单元中。只有在付款人单元的MCI和下一个MCI变得稳定之后才选择接收者。为了确定接收者，我们选取那些MCI等于或大于付款人MCI的子单元。这些子单元的每个哈希值与位于下一个MCI上(相对于付款人)的单元的哈希值相连接，并且具有最小哈希值(十六进制)的子单元赢得标头佣金。

设计下一个MC单元的哈希是为了引入不可预测性(下一个MC单元不是预先知道的)，并且没有任何尝试或提高接收佣金的机会或通过使用自己的单元哈希来实现无效。同时，将候选人限定为那些MCI不大于1的人，这好于MCI不大于1的付款人。鼓励选择最近的单元作为父母。这对于保持DAG尽可能的精确是有用的。

我们只支付标头佣金，而不是将全部佣金给那些很快选择我们单元作为父母的人，原因如下：如果我们支付了整个佣金，我们会激励滥用行为：将一个数据分成几个块，并构建一个自身单元的长链来存储每单元的一个块。在前一个单元支付的所有佣金，将立即由下一个单元的同一用户收集起来。由于我们只支付标头佣金，这样的行为是无利可图的，因为要生产链上的额外元素，必须花费额外的标头佣金-大致等于收入的一个费用。我们使用剩余(有效载荷)佣金来激励对于保持网络健康很重要的活动。

有效载荷佣金转给证人。为了激励证人频繁活动，我们将有效载荷佣金平均分配给所有的证人，在支付单元后他们迅速发布100个MC索引(发布速度越快，该单位变得越稳定)。如果在此间隔内，12名证人都发布索引，则每个人收到1 / 12的有效载荷佣金。如果只有一个证人发布，他会收到所有的有效载荷佣金。在特定情况下，没有证人在间隔内发布，他们都会收到1/12的有效载荷佣金。如果除法产生小数，则根据数学规则四舍五入。由于四舍五入，支付给证人的总佣金可能不等于从该单元的作者中收到的总有效载荷佣金，所以总货币供应量也会略有变化。显然，仅在MCI + 100变得稳定之后才分发，其中MCI是付费单元的MCI。

简单支付认证

不运行完全节点也可验证支付，用户只需要保存所有的block header就可以了。用户虽然不能自己验证交易，但如果能够从区块链的某处找到相符的交易，他就可以知道网络已经认可了这笔交易，而且得到了网络的多少个确认。