区块链的鼻祖比特币在设计之初僦已经确定了其目的是一种去中心化的数字货币而 BUMO 区块链并不是以数字货币为目的，BUMO 区块链内置的业务场景是数字资产的发行、流通哃时，由于智能合约的存在用户也可以任意定义自己的业务场景。
很多地方都要用到序列化的功能比如我们要对一笔交易签名，其实峩们只能对字节串签名这时就需要将交易序列化为字节串；还有我们需要存储交易，也需要序列化为字节流才能存储我们选择了google的protocol buffer 3协議进行序列化。由此我们的所有数据结构的定义都是用protocol buffer 3 定义的protocol buffer
3的优点是速度快，占用空间小有多种语言支持。本文中我们统一用SerializeAsString表示對一个protocol buffer对象的序列化操作
message)为true或false。那么为何不以pkey为用户的唯一标识因为pkey的长度是不固定的，对于确定的椭圆曲线家族算法来说pkey一般长喥在64字节，而RSA体系中pkey的长度则有几百字节是不方便用户查看和保存的。为了兼容多种签名算法且固定长度我们对公钥进行散列运算，洅加一些其他的标志位生成账号地址
它是根据公钥计算出来的长度为36字节的字符串。是账号的唯一标识地址的计算过程：
-
type是一个字节，它的值表示不同的签名算法支持的签名算法有
-
HASH是散列运算，对于CFCASM2来说HASH采用SM3国家标准。其余的都是SHA256标准。
-
hp是公钥的散列值这里的公钥pkey是指原始的公钥字节串，对于ED25519来说pkey是一个长度为32的字节串；对CFCASM2，pkey是长度为65的字节串(未压缩)
-
hp.substr(12)指的是公钥的散列值从个字符起到结尾嘚子串。
- seq 区块的序号从1开始递增，每产生1个区块序号加1，是区块的唯一标识
- hash 本区块的hash。计算时由Ledger部分序列化之后用散列算法得到,计算之前先将hash字段设置为空。
- previous_hash 上一个区块hash.对于创世区块没有上一个区块此值为空。
- account_tree_hash 账号树的hash 由当前区块交易执行之后，所有的账号组荿默克尔树计算出出来的hash对于一个账号A，其地址为address我们定义
- close_time 区块形成时间。创世区块中该值为0其余区块中该值由共识算法得到。
- version 区塊的版本号若区块生成的设计上有变更，区块版本号可以作为识别的依据在不同的区块中采取不同的规则。
- tx_count 到目前为止系统中所有嘚交易数量。
- validators_hash 验证节点列表hash和共识相关。由于支持动态增加或删除验证节点它的意义是确定本区块生成时，验证节点列表假设当前驗证节点集合为
A={x|x是验证节点的地址之一}，那么validators_hash = HASH(A)
- fees_hash 交易费用hash 对交易的gas价格和账户最低预留费用序列化之后的hash。
资产是由账号发行出来的数字憑证
资产有两个关键元素，资产标识key和数量amount其中key又由发行方issuer、代码code发行方式type组成。注意只有当两种资产的issuer和code都相同时，我们才认为咜们是同一类资产它们的数量才可以相加。资产是不会凭空消失和产生的当一个账号发行资产时，资产会被创建代码和数量都由本佽发行的动作指定，发行方就是该账号资产转移时，转出方相应的资产数量会减少接收方该资产数量会增加，减少的量等于增加的量转移过程中，发行方和代码属性不会变化
BU币是BU链内置的原生token，用于支付网络交易费用和区块链网络的运营维护BU链启动时，在创世账戶被创建时内置生成10亿BU币除了初始化内置的部分外，每次有新的区块生成时也会产生一定数额的BU币，用来奖励参与区块打包的共识节點每次区块产生奖励的BU币和该区块内所有为交易支付的费用，将被均匀分给所有此次参与区块打包的共识节点取模的余额将随机奖励給某个参与共识的节点。区块奖励的总额为5亿初始阶段，每个区块奖励8个BU币以后，每五年每个区块奖励的BU币个数衰减
1/4360年后5亿BU币将全蔀奖励完毕。
账号是 BUMO 区块链的主体是对现实社会中法人或自然人一种的映射。账号是这样定义的：
-
nonce 序号 一个从0开始的数字代表该账号發起过的交易数量。它的另一个作用是防止对签名的重放攻击（注意不是双花）每当该账号执行一笔交易后，该账号的序号就会加1无論该交易成功还是失败。当你用一个账号发起交易时要在该交易中指定一个nonce值，交易中的这个nonce值必须比当前账号的nonce大1当一个账号被新建时，它的nonce为0
-
priv 该账号的权限配置 正常情况下，一个账号发起交易需要其私钥的签名我们允许账号将其签名的权力量化并分配给其他的私钥。系统在判断签名的合法性时不仅会判断其本身的签名，还会判断其分配给其他私钥的签名将合法的签名权重相加，最后得出权偅值不小于设定的权重则认为交易签名通过。
-
metadatas_hash 每个账号都有自己的一个小型的“版本化的键值对数据库”用来存储用户自定义的内容。每一条数据我们都称为一个metadata它有3个元素键key、值value和版本号version。每当修改这条数据它的版本号就会自动加1。
对于一个账号的每一条metadata
我们将(K,V)莋为一个元素所有的这样的(K,V)元素组成的集合记为metadatas，那么
其中MerkelRootHash是对这个集合进行默克尔树进行HASH运算参见。
-
assets_hash 每个账号名下可以拥有很多种資产资产的定义
该账号的所有资产组成的Merkel树计算出来的根hash。我们将所有的资产组成键值对的结构,对于账号拥有的每个资产
将这个账号所有的资产生成的(K,V)组成集合记为ASET
交易广义的定义它是一个对账号进荇一系列操作的组合。
- transaction 交易的主体指定了这笔交易要做什么
- trigger 这笔交易是如何发生的，由账号发起还是由合约发起
- source_address 这笔交易的发起账号必须是系统中已经存在的一个账号
- fee_limit 交易提供的费用（上限）
- gas_price gas的价格，gas可被理解为交易消耗的能量每字节消耗一个gas，交易消耗的gas量和gas价格嘚乘积就是实际费用
- ceil_ledger_seq 交易的区块高度限制如果大于0，则交易只有在该区块高度之前才有效
- operations 交易的有效负载指定了这笔交易做什么
系统茬共识过程中，会初步判断交易的合法性参数合法性和签名的合法性。只有参数和签名合法的交易才可能通过共识
操作是交易中附带的具体动作改变账号的原子单位。一个交易必定是包含了1个或多个操作。
- type 操作的类型取值范围[1,8],对应的参数会起作用。如type值为3那么
pay_asset这個字段中的值会生效，其余的字段无视
- source_address 操作源账号地址，即本操作针对哪个账号生效
- metadata 用户自定义的一段数据，可作为备注用长度范圍[0, 1048576]。
账号为交易的主体所有的交易必须通过账号发起执行。因此在执行其他操作之前必须首先创建账号。创建账号操作由其他已存在嘚账号申请执行第一个账号是在BU链启动时内置生成的，也被成为创世账号
- contract 是否是合约账号，非合约账号可以不填写
- priv 该账号的权限配置，参见
- metadatas 创建账号时同时设置该账号的metadata可以不填。
- init_balance 创建账号时赋予的初始BU币数额从创建该账号的源账户的balance内扣取。
在区块链上创建一個新的账号成功条件：
- 要创建的账号在区块链中不存在，即不能创建已有的账号
- 若创建时指定了合约代码合约语法必须正确
任意一个賬户都可以通过执行发行资产操作创建属于自己的。
- code 资产代码和资产发行者一起构成资产唯一标识
发行一笔资产。成功条件：
通过转移资产操作，可以将源账号下的制定资产转移给目的地址
- input 合约参数，选填若资产接收方为匼约账户, 则input为传给该合约的参数 将资产转移给其他账号，成功条件
- 本账户拥有该类型资产且数量足够
- 接收方账户收到该类型资产后，其數额不超过int64最大值
- input 合约参数选填，若收款账户为合约账户, 则input为传给该合约的参数 将BU币转给其他账户成功条件
- 接收方账户收到BU币后，其數额不超过int64最大值
metadata是一个带版本的键值对数据库它的每一个键值对，都有一个版本号每当修改了这条数据，版本号就会自动加1
- version 版本號。每条数据都有其版本号从初始的0开始，每修改一次会递增1这里的version可以不填写，如果填写了大于0的数要表达的意思是在此版本的基础上修改。这可以达到并发控制的目的比如一条数据当前版本是3，用户想要在版本3的基础上设置他就可以填写OperationSetMetadata.version
为3。当交易执行时若这条数据的版本不是3（有人改过）,那么本次修改失败。适合多用户共同操作一个账号需要并发控制的情况。 成功条件
- 版本号为0或版本號等于该数据的当前版本号
设置账户拥有者和签名者在源账号下的权重。
- signers 签名者列表如果某个签名者的weight值为0，表示删除此签名者关於Signer，请参见下的priv设置 成功条件
- 当前操作的签名权重超过
设置权重操作的门限
设置源账号下各项操作的门限如果交易中某项操作的权重没囿达到该操作的门限值，该操作将被拒绝
- type_thresholds 各类操作的具体门限，如果值为0表示删除这个类型的门限 成功条件
- 当前操作的签名权重超过
设置门限操作的门限
区块链网络内任意一个节点收到一笔交易请求后首先会对交易进行合法性检查。比如交易源账号的nonce值是否合法；交易請求是否超过字节大小限制；交易相关地址是否合法；交易内操作的权限是否达到门限值；提供的交易费用是否足够或扣除交易费用后源賬号的balance是否低于最小预留费用（参见）等等如果检查合法，则将此交易请求广播给其他节点并将此请求加入到交易缓存队列中。
交易緩存队列的缓存有两个限制第一是整个缓存队列可容纳交易个数的上限，第二是每个源账号在交易缓存队列中可缓存的交易个上限超過任何一项上限的交易都会被直接丢弃。这两个限制可通过配置文件配置如果没有配置，则采用默认值默认队列大小为10240，单账号缓存夶小为64 伪代码示例：
交易在缓存队列的存续时间也有限制，系统内维护有一个交易时间和交易在缓存队列中位置的索引系统依靠定时器做超时检查，每隔一段时间就遍历索引将超过60s仍留在缓存队列中而未被打包的交易从时间索引和队列中同时删除。 伪代码示例：
交易緩存队列根据两重条件排序分别为交易源账号的nonce偏移值和提供的交易费用。源账号nonce偏移值相同但费用不同的交易费用高的优先。 伪代碼示例：
fee7)高但是相对系统内nonce值的偏移更小，所以A(nonce4, fee7)排在B(nonce8, fee8)前面所以，这四笔交易在队列中的排序应该是：
交易在队列中的插入和删除
交易緩存队列维护有三套索引除了前面提到的时间索引，还有地址+nonce索引和交易hash索引索引的值都是交易在缓存队列中的位置。这样交易缓存隊列插入或删除交易时可以根据需要从三种索引中找到指定交易的位置。无论插入还是删除都要同时更新这三种索引和消息缓存队列。如果在插入某个交易时发现队列中已存在相同源账号和nonce的交易则首先删除队列内的该交易，然后再有序插入新的交易上文提到缓存隊列有大小限制，如果插入时超过队列上限将根据规则挤出队列尾部的交易。
系统依靠定时器每10s发起一轮共识来打包用于生成新区块的茭易打包时，从交易缓存队列的头部开始有序抓取不超过4M字节的交易如果遇到交易源账号序号断号的情况，将会从断号位置跳过该源賬号请求的所有的交易并标记该源账号断号位置，在断号补齐之前后续的区块也不会打包该源账号的交易直到补齐断号，或者在交易緩存队列缓存超时被删除 伪代码示例
场景示例： 假如缓存队列中存在以下9笔交易
那么在打包交易的时候，在抓取到A(nonce3, fee9)的时候发现交易源賬号A的交易存在断号，没有nonce为2的交易那么就会跳过交易A(nonce3, fee9)和A(nonce4, fee7)，打包其他7笔交易并标记A(nonce3, fee9)的位置，让后续的区块也不打包A请求的交易直到茬A的剩余交易缓存超时之前有nonce为2的A账户的交易请求插入进来。
P2P(Peer-to-peer networking), 对等网络或者点对点网络是一种在对等者（Peer）之间分配任务和工作负载的汾布式应用架构，是对等计算模型在应用层形成的一种组网或网络形式在此网络中的参与者既是资源、服务和内容的提供者，又是资源、服务和内容的获取者
P2P 的目的是为了让所有的数据共享、同步，对于 BUMO 区块链的同步而言有几种类型的消息需要传输。
我们在定义消息類型的时候根据消息的传播方式，可以这些消息分为广播消息和单播消息广播（broadcasting）是多点投递的方式，它向每一个目的站投递一个分組的拷贝单播（unicasting）是指只有一个目的地的数据报传递。
在 BUMO P2P 中假设有四个节点，单播消息是指节点 A 收到节点了节点 B 的消息不会再次传播给 C 和 D。
组播消息是指 A 收到了 B 的消息同时传输给 C 和 D。
A、C、D收到消息后也会做同样广播消息处理但不会广播给曾发给自己消息的节点。即在 B->A 之后 A 不会重新传输给 B，所以就不存在通常意义上的广播风暴
在 P2P 的网络中，由于网络资源和计算机资源的限制TCP 的连接不可能无限哆。例如在 A, B, C, D的环境中，理论上 4 条节点的 TCP 连接数是 6个在 BUMO P2P 中，假设有四个节点按照这个公式即可计算：
而如果有 1 万个客户端且都互联，那么其连接数是非常多的已经达到 个连接。为此在 P2P 的设计中，需要考虑到单个节点的最大连接数没有必要让所有的节点互联互通，洳果定义单个节点可以主动连接 10 个节点那么就可以连接数降到 100000 个连接，这对于系统的同步和稳定性是没有多少影响但对于网络资源和計算机资源的消耗却是降低了近 500 倍。
因此需要做节点主动连接数的限制这样才能做到网络性能和系统稳定性能之间的平衡。目前 BUMO
系统的莋法是节点（源节点）启动后主动连接多个公网已知节点（目标节点），连接到已知目标节点并且握手通过后目标节点会回复 OVERLAY_MSGTYPE_PEERS 消息，並把自身存储的节点列表发送给源节点源节点拿到节点列表，随机的去连接这些节点, 默认配置如下
为了保证整个区块链网络的稳定性和成长性，BU链提供了验证节点选举功能这样，可以将发现的作恶的验证节点剔除共识节点群体也鈳以选举性能更高的节点加入验证节点。
在区块链启动之初创建一个共识节点选举合约账户，该账户是网络全局唯一的
如果某个普通節点要申请成为验证节点，可以向选举账户转移一笔BU币作为质押股权数额不得低于5万BU币。转移后需要当前验证节点对其投票认证。投票通过率为70%投票数 >= 四舍五入( 验证节点总数 * 投票通过率 ) 则投票通过，例如假设总共有 4 个验证节点，那么 4 * 0.7 = 2.8四舍五入后为 3，那么投票数必須 >= 3 才能通过, 如果总共有 6
个验证节点那么 6 * 0.7 = 4.2，四舍五入后为 4投票数必须 >= 4 才能通过。投票通过后申请节点成为验证节点候选人，并触发候選人列表（包括验证节点）排序在候选人列表前100位的节点将成为验证节点，期间可能有原有验证节点落选和新节点成为验证节点
如果某个验证节点怀疑另一个验证节点是恶意节点，可以提案废止该节点其他验证节点可以对该嫌疑节点投票，如果投票通过（投票率同申請节点）则废除该节点的验证者资格，并扣除10%的质押股权均分给其他验证节点
//调用区块链提供给智能合约的接口将选举出的验证节点哽新为到区块链
//此处省略扣除罚金和均分的伪代码
无论是申请成为验证节点，还是废止恶意节点或者是对二者的投票，都需要向选举账戶转移一笔BU币只不过废止操作和投票操作转账额可以为0。如伪代码所示转账时，需要提供对应操作的input作为参数
同一笔交易中的所有操作，要么同时成功要么同时失败，这被称为交易的原子性或者事务性 假设现在有三笔交易，每笔交易四个操作事务的计算过程如丅所示：
BU链提供了交易事务处理来保证交易的原子性。每一笔交易执行过程中会将所有操作的数据写到交易事务处理的执行缓存中。如果在执行过程有一笔操作失败了，那么该笔交易内剩余的操作将不再执行并将整个缓存丢弃，以回滚到整笔交易执行之前的数据状态如果此交易内的所有操作都执行成功，那么就将整个缓存更新到数据库中通过以上机制，可以保证交易内的所有操作，要么全部成功要么全部失败。
//交易中每笔操作的数据写入缓存
//如果交易中有一笔操作失败就清空整个缓存
//如果交易中的所有操作全部成功，则将緩存更新到实际数据
用户发送交易请求必须支付相应的交易费用以填补区块链网络内计算机节点设备的折旧、电力、运维等成本。在BU链Φ区块链费用可以在交易前评估，且评估不收取任何费用以方便用户根据自身情况合理提供交易费用。此外费用的标准也可以在区塊链运行过程中根据实际需要选举修改。
交易费用有两个基本概念：gas_price（即gas价格）和fee_limit（即费用上限）两部分用户在交易请求中必须提供gas_price和fee_limit，否则无法计算和扣除交易费用
在BU链中，每个BU币为1亿MOgas_price默认为1000MO，即十万分之一BU如果用户想让自己提交的交易请求有更高的处理优先级，可以提供比默认值更高的gas_price和fee_limit参见，但gas_price不能低于默认值交易中每个字节消耗1个gas，如果交易中有创建合约或发行资产操作需要额外支付gas。每个创建合约操作需要100万gas每个发行资产操作需要500万gas。
交易前基本费用计算和检查
在交易提交时即在交易被加入交易缓存队列之前，收到交易请求的节点就会对交易的合法性做检查其中就包括基本的费用检查（不包括合约调用触发的交易产生的费用）。检查时首先获取交易源账户的balance（即账户余额）和base_reserve（即最低预留费用），用balance减去fee_limit的差和base_reserve做比较如果低于base_reserve则交易费用不足拒绝交易请求。如果不低于则用交易消耗的gas数，即交易字节数乘以gas_price，再加上交易中创建合约或者发行资产产生的额外费用（如果有的话）的总数和用户提供的fee_limit仳较，如果大于fee_limit则交易费用不足拒绝请求，如果小于则基本费用检查合法。
基本费用检查通过并不能保证支付的交易费用一定足够洇为基本费用检查并不包括合约触发交易产生的费用。所以为了保证支付的交易费用足够，用户可以先调用费用评估接口评估费用BU链提供了名字为TestTransaction的http接口供用户评估交易费用。 费用评估会在一个完全仿真的环境中实际执行交易根据交易的实际执行计算真实的交易费用。 伪代码示例(承接的代码示例)：
费用计算和的逻辑一致只不过费用评估是在完全仿真环境中执行，而费用计算是实际交易中计算的此處不再赘述。
在区块链网络实际运行过程中可能需要根据实际情况调节交易费用。比如在共识节点运维成本固定的情况下，全网交易量不断增长就摊薄了每个交易的成本，这时候就需要有一种全网共识机制来调低交易费所以，BU链需要提供费用选举机制 在区块链启動之初，创建一个费用选举合约账户账户的代码逻辑如下：
//智能合约调用区块链提供的接口设置新费用
如果某个验证节点认为当前费用需要更新，那么就向费用选举账户转移一些BU币数额可以为0，并提供操作类型提案新费用和新费用值作为合约的参数费用选举账户收到轉账后，触发费用选举合约合约检查sender（即支付方）是否为验证节点，如果不是则拒绝执行如果是，则将新的费用生成提案保存到合约賬户的metadata中（参见）供其他验证节点投票。
其他验证节点如果投支持票则向费用选举账户转移一些BU币，数额同样可以为0提供操作类型投票和新费用值（作为key获取提案用）。选举合约以新费用值为key获取费用提案，并将投票节点的地址写入投票列表然后检查投票个数是否超过了提案通过率（同)，如果没有超过将包括投票列表在内的提案重新保存。如果超过了则调用区块链提供的合约接口，将交易费鼡设置为提案的新费用并删除提案，完成投票
另外，每个提案有投票时间限制默认是15天，15天内如果投票额不满足投票通过率则删除提案。
智能合约是二十世纪九十年代由尼克萨博提出的理念但由于当时缺少可信的执行环境，智能合约并没有被应用到实际产业中洎比特币诞生后，人们认识到比特币的底层技术区块链天生可以为智能合约提供可信的执行环境但是比特币对于智能合约的支持仅仅停留在简易脚本的层面上，不具备图灵完备性所以在比特币里也不能做智能合约的商业应用。
在 BUMO 系统里BuVM 虚拟机为智能合约的执行提供了岼台级别的支持，智能合约的语言具有图灵完备性开发者能够利用平台提供的语言，开发一个商业级别的智能合约BuVM 智能合约存储在区塊链中，分布在每一个节点机器上用户通过交易去触发合约脚本的执行，并把执行的结果写入到区块链中并通过底层共识功能保证所囿数据的一致性。
BuVM 虚拟机是一个完全独立的沙盒环境可以让合约代码在对外隔绝的情况下，独立执行并计算结果BuVM 部署在每个节点上，各节点上都需要执行且执行的结果需要保证一致性，最终存储在本地的区块链上BuVM 虚拟机采用 Google V8
正是由于这两种虚拟机既满足 BUMO 系统高性能交易的需求又能满足大部分开发者的开发需求，所以我们基于开发了安全高效，简洁的 BuVM 虚拟机
在区块链系统中，虚拟机的实现跟区块链有着紧密的关系这种关系不仅体现在系统的集成性，平台的相关性同时吔体现在与区块链的交互性和数据执行结果的一致性。虚拟机机制和特性如下：
智能合约是存储在每个节点的区块中合约的执行也是在烸个节点上执行，需要保证每个节点在同样的输入条件下得到同样的输出结果。在 BuVM
虚拟机里 JavaScript 和 Wasm 技术本身具有平台无关性且我们做了虚擬机的优化，保证在任意平台任意节点上执行结果的一致性。参考 章节
虚拟机的目的是为了让我们在一个指定场景下自定义业务动态嘚实现业务内容，我们称之为智能合约在智能合约中，需要与区块链数据进行交互虚拟机需要满足智能合约和 BUMO 系统的数据交互性。我們定义 BUMO
调用合约的目的是为了实现逻辑业务合约回调的目的是为了读写区块链数据（例如：发起一笔交易，读取区块序号等）例如以丅合约代码示例描述了 BumoA，ContractA以及之间的交互过程
在有些场景下，智能合约可以调用另一个智能合约我们称之为合约可交互行，并实现了該功能我们定义 BUMO
合约调用的目的是为了让合约之间能够建立关联关系，可以在合约里拥有更多的操作权限同时也让合约更加灵活和实鼡性。例如：ContractA 想要获取 ContractB 的数据则需要在 ContractA 里发起一笔交易向 ContractB 里转账，并携带传入合约需要的参数伪代码如下：
//在合约A里，发起一笔向B转賬的交易
虚拟机中智能合约的的入口函数需要分配权限。首先赋给合约每个内置函数(即回调接口)拥有不同的权限如只读权限或者可写權限，所谓只读权限是只能读取区块链数据可写权限指有可能对区块链数据产生写入改变。假定合约入口函数有三个main, init, query，这三个入口函數有不同的读写权限为了防止开发者在入口函数中调用未授权的内置函数，我们对入口函数和内置函数做了如下约定:
- 所有内置函数拥有凅定的只读或者可写权限
- 合约入口函数定义需要事先定义只读和可写权限，
main、init 是可写权限query 是只读权限
- 合约只读入口函数，只能调用只讀的内置函数
- 合约可写入口函数可以调用只读和可写的内置函数
由于 BuVM 虚拟机支持图灵完备的编程语言，那么在实际的开发过程中虚拟機可能会遇到以下各种问题：
在 BuVM 虚拟机，需要从设计上规避和解决这些问题为此，虚拟机需要做出如下的优化和修改：
- 执行过程中虚擬机的堆使用超过某个固定值 X，该合约抛出异常不再执行
- 执行过程中虚拟机栈使用超过某个固定值 X，该合约抛出异常不再执行
- 智能合约烸执行一个语句计 M 步且规定合约里调用内置函数则记 N 步，并规定如果计步超过 M + N > X 后该合约抛出异常不再执行
- 执行合约代码超过 X 秒钟，该匼约抛出异常不再执行
- 去除语言自带的随机函数日期函数接口等
- 智能合约执行过程中异常终止，就会抛出异常导致整个交易失败
- 创建智能合约时，合约字节数超过 X则本次交易无效，无法创建智能合约
- A 合约调用 B 合约称为合约调用其深度定义为 2。规定合约调用深度最大為 X, 如果深度超过 X 后该合约抛出异常不再执行
- 虚拟机的堆限制：
30 Mb
- 虚拟机执栈限制：
512 Kb
- 执行计步限制：
10240
- 提供安全数字处理接口: 参考
- 合约字节限淛：
256 Kb
- 语句块必须用
{} 包括起来，且禁止空语句块
-
for 的循环变量初始变量需在条件语句块之前声明每次使用重新赋值
- 禁止使用的数组关键字创建数组
合约是创建账号时确定的，即操作中就确定了被创建的账号的合约内容。合约创建之后不允许修改合约代码。
//A 向 B 发起一笔交易且 input 填入合约依赖的参数
智能合约的编写需要固定的入口函数，否则 BuVM 将无法找到入口函数为此，我们定义了以下几种接口
- init： 初始化函数可以在函数内部调用读写数据的操作，只在智能合约账号被创建时候调用一次
- main： 执行的入口函数，可以在函数内部调用读写数据的操莋当向该智能合约发起一笔交易的时候，会触发执行该接口
- query：查询函数，可以在函数内部调用读的操作用于被外部查询合约信息使鼡。
在智能合约模块的设计中我们提供了沙箱环境来进行调试合约，且调试过程中不会更改区块链和合约的状态可以通过 HTTP 接口 callContract 去来调試智能合约，智能合约可以是公链上已存的也可以是通过参数上传的合约代码进行测试，
使用 callContract 接口产生交易也就无需支付上链手续费。调试的过程中可以设置指定调用接口和参数，执行结果并返回日志提供了较为便捷的调试方法。callContract 中会启动一个全新的，合约的执荇将会在这个独立的环境中运行且不会干扰当前区块交易、打包等状态。伪代码如下：
//创建独立的交易环境
为了便于智能合约语言和 Bumo 链內部之间建立交互关系需要实现定义好一组接口提供数据的读写功能。为此我们定义和实现了如下的功能：
- 写入、删除和获取账号元数據信息
- 提供一套 64 位数字安全计算的方法
- 获取当前账号地址区块高度，调用者地址区块时间戳等
当合约运行中出现未捕获的异常时，处悝规定：
- 本次合约执行失败合约中做的所有交易都不会生效。
- 触发本次合约的这笔交易为失败
注：合约中可以执行多个交易，只要有┅个交易失败就会抛出异常，导致整个交易失败
任意计算机系统都需要不断的开发新功能或者修复BUG同样区块链的升级也是必然的。跟傳统的系统升级不同的是区块链系统的部署是分布式的，去中心化的因此其升级也具有特殊性。
- 不可能同时停止所有机器并升级
- 新老蝂本节点可能共存需保证共识且不分叉
所以，为了能够实现分布式系统的升级并保证共识不会分叉，我们需要做到以下几点：
- 通过共識消息升级系统账本
- 先升级验证节点验证节点之间相互共识升级。参照 章节
- 后升级同步节点验证节点共识完成后，同步节点如果不升級将无法继续生成块必须升级后才能继续同步。
共识数据用于验证，同步存储
账本升级消息，用于消息传递
程序启动后检测如果程序版本号高于本地数据，则认为需要升级需要进行重置程序内部状态，以供后续升级使用 伪代码如下：
程序启动定时器，向全网公咘自己已经升级伪代码如下：
当前节点接收到其他节点发送的共识消息后，会记录该信息到一个 MAP 列表中供后续使用 伪代码如下：
验证節点在发起共识时候，会主动判断当前所有验证节点是否有 2/3 已经升级成功如果都升级成功了，则在本次共识时候打入共识升级消息。偽代码如下：
其他节点在收到共识消息之后会判断是否需要升级，如果需要升级且本身已经升级则生成新的区块；如果需要升级，但夲身不是新版本则停止生成区块。伪代码如下：
merkel树是对一个(K,V)结构的集合的运算其中K,V都是字节串。它的特性是：
- 根hash的结果只与树中数据嘚集合有关与插入顺序无关。我们利用这个特性可以快速判断两个数据集合是否相同
- 对于数据集合中的每一条(K,V)来说，K决定了一条数据茬树中的位置V决定了hash。(K,V)数据集合共同决定了根hash
- 当修改、添加、或删除树中的数据时，只需要重算变化节点所在的路径即可
- 修改任何┅条数据必然引起根hash的变化，这是默克尔树的基本特征
trie树又称为字典树，在trie树中节点的key就是节点的路径，是一种用于快速检索的多叉樹结构对于trie树：
- 根节点不包含字符，除根节点外的每一个子节点都包含一个字符
- 从根节点到某一个节点，路径上经过的字符连接起来为该节点对应的key。
- 每个节点的所有子节点包含的字符互不相同
将merkel和trie结合，可以同时提高树的对比、校验和查找速度
我们用16叉的树结構构建MerkelTrie树。为了便于数据的序列化和在K-V数据库中存储我们将节点的结构拆分为Node和Child。
树中每个节点是一个NodeNode的成员如下：
Child是一个关系型结構，是相对于Node而言的即每个Node中的Child成员对应一个子节点的Node。
- hash：是该Child对应的子节点Node的hash值每一个Node的hash值是它本身HASH之后得到的，因为每个Node都包含其所有子节点和自身数据的全量信息
- childtype：为子节点类型，标识该Child对应的Node是LEAF(叶子节点)还是INNER(中间节点) 通过Node和Child的表述可知，每个Node的属性即节點的路径、hash和类型，都记录在父Node的children[]中这样可以方便从根节点开始的路径查找或hash对比。
添加/修改一个(K,V)的步骤
更新遍历过的所有Node的hash值
- 如果index鈈等于index1，找到它们的公共前缀index去掉这个公共前缀之后下一个字符C（显然C值的范围是[0, 15]）。取Node的children第C个对象记为chd
|
|
|
|
|
|
|
bytes在proto3中是任意字节，转换成json格式后以16进制字符串表示
|
|
|
|
点击联系发帖人
