第六章 基本概念
UOS看似庞大复杂，是因为它提出了一些与其他区块链截然不同的概念。本章介绍UOS系统中的一些基本概念，在阅读本章之前，希望大家注意的是: UOS同绝大多数区块链一样，通过许多节点冗余工作确保共识的准确，所以节点数目的增加带来的是链的安全性增加，并不能带来资源的增加。
6.1 账户
账户是对UOS用户的指代，于UOS而言，每一个账户即一个用户。UOS账户名称由小写字母a-z,数字1-5组成，普通用户的长度为12位，小于12位的称为短号，短号要通过竞拍，或者由其他短号创建获得。 用命令查看一个UOS的账户：
cluos --url http://rpc.uos.iccob.com:9008 get account "baodaotulong"
created: 2019-03-29T08:46:56.000
permissions:
owner 1: 1 UOS5A4sYXU6SA5kyKjbu76r9xapgrzotjhLEgPSZzDzMBJpw1559Y
active 1: 1 UOS5A4sYXU6SA5kyKjbu76r9xapgrzotjhLEgPSZzDzMBJpw1559Y
memory:
quota: 3.491 KiB used: 3.49 KiB
net bandwidth:
staked: 0.1000 UOS (total stake delegated from account to self)
delegated: 0.0000 UOS (total staked delegated to account from others)
used: 432 bytes
available: 15.63 MiB
limit: 15.63 MiB
cpu bandwidth:
staked: 0.1000 UOS (total stake delegated from account to self)
delegated: 0.0000 UOS (total staked delegated to account from others)
used: 2.939 ms
available: 2.122 sec
limit: 2.125 sec
UOS balances:
liquid: 1.3648 UOS
staked: 0.2000 UOS
unstaking: 0.0000 UOS
total: 1.5648 UOS
producers:
staked: 0.2000 UOS
<not voted>
total: 0.0000 UOS一个账户的基本信息包含权限组成、内存信息、cpu信息、net信息、余额信息、投票信息。
6.1.1 权限组成
UOS的账户默认有两个权限：owner和active。拥有对应权限的私钥，便可以用使用该用户的相应权限。active权限用来进行一般操作，比如转账、购买内存、抵押、投票调用一般合约。owner权限能行使active权限的一切操作，并且能够修改用户的active权限组成和owner权限组成。 比如：baodaotulong的owner和active权限均是由公钥组成：
UOS5A4sYXU6SA5kyKjbu76r9xapgrzotjhLEgPSZzDzMBJpw1559Y
那么，只要拥有上面公钥对应的私钥，我们便可以在地球上每一个有网络的地方使用“baodaotulong”账户active或者owner身份进行的任何合法操作。我们把用户某权限的私钥称为该用户该权限的权限私钥。 账户的某一权限可以由公钥组成，也可以有其他账户的权限组成(比如uosio.prods)，或者由他们相互结合组成。若是A账户的X权限由B账户Y权限组成，则拥有B账户Y权限的“权限私钥”就可以解锁A的X权限。 对如下权限：
active 1: 1 UOS5A4sYXU6SA5kyKjbu76r9xapgrzotjhLEgPSZzDzMBJpw1559Y
active的后的第一个“１”是权限阈值，公钥前面的“１”是该公钥的权重，要解锁某一权限，需要权限私钥对应的权重之和要能大于或等于权限阈值。关于权限更多介绍，可以跳转到多重签名章节。 内存信息、cpu信息、net信息和投票信息将在以后的章节中介绍。
6.1.2 权限修改
UOS系统中，我们可以修改账户的权限组成，或增加新的权限。以baodaotulong账户为例，我们先查看该账户的权限：
修改active权限
需要active权限或owner权限。
修改后查看账户权限组成：
修改owner权限
必须使用owner权限。
修改后查看账户权限组成：
注意：以上命令也可以修改权限的权重和阈值；修改owner权限时，我们就修改了该权限的权重及阈值。
创建或修改其他权限
除了两个原生权限以外，UOS还支持自定义权限。我们新增一个voting权限，该权限是active的子权限。且该权限由 UOS5BmFG8H42XvKGN1Lfq94iDgwHoQCgtCPCqvoeN6ibqCHhi7XX9 对应的私钥和testaccountx的active权限共同控制。
修改后查看账户权限组成：
注意：新增voting权限后，并不能直接使用该权限进行任何操作，我们还需要给该权限绑定action。
绑定action
这里，我们绑定uosio合约的voteproducer这个action。
当然我们也可以给voting权限绑定多个action，如转账。
解除绑定
移除权限之前，我们需要解绑该权限绑定的所有action，否则无法移除。
移除权限
既然可以新增权限，当然也可以移除权限。
修改后查看账户权限组成：
6.2 交易
UOS中，任何一个操作最后均归结为合约的调用，交易实际是由用户授权的一个或多个合约调用的组合。
6.2.1 交易组成
一个交易包含一个或多个action,每一个action对应一次合约的直接调用。比如一条转账交易，是调用uosio.token合约的transfer操作，一条交易可以用一个json来描述，可以通过http命令把某个合法交易的json发送给节点打包执行。如id为如下的交易
366616970c7995a935e3263571bd543937a6512cc358c66a91ed449fbb0dcd21
expiration：交易的过期时间，交易在UOS上的最迟执行时间，如果交易在expiration还未执行，则此交易再也不会被执行。 ref_block_num：交易的参考区块号 ref_block_prefix：交易的参考区块的hash前缀 max_net_usage_words：交易的net使用上限，为０不设限制 max_cpu_usage_ms：交易的cpu使用上限，为０不受限制 delay_sec：交易的延迟时间，为０代表非延迟交易 context_free_actions：上下文无关的行为。
6.2.3 actions
此交易的具体调用的合约，上文中的转账交易直接调用的合约的文字解释如下：
6.2.4 signatures
此交易的签名。需要与actions声明的调用权限一致，如果声明了uosiopokerbp的active权限，就需要用uosiopokerbp账号active权限的权限私钥进行签名。 在区块链浏览器上查看这条交易： https://explorer.uosio.org/transactions/5513440/366616970c7995a935e3263571bd543937a6512cc358c66a91ed449fbb0dcd21
6.3 内存、cpu、net
uos的资源包含：cpu、net、内存(ram)。用户的每个操作都需要链来执行，执行需要花费一定的cpu资源，而每个操作都是用数据来进行表达的，需要在区块中占据一定的容量，用net资源计量。合约需要非易失性的存储某些数据，事实上，这些非易失性数据是存在与每一个节点上，是物理受限的，这些以ram计量。 这一节我们还是用“baodaotulong”这个账号举例：
6.3.1 内存
UOS的节点本质运行在具体的物理计算机上的一个程序，这个程序将一些常用的数据储存在计算机的内存之中，账户的基本信息便是其中的一种。由于UOS的区块链特性，为了确保“共识”的准确，每一个节点运行的程序是一样的，所以每一个节点的UOS程序在内存中存储的是同一份状态数据，因此内存资源的容量于节点数目无关，并不会因为节点的增多而增多。因为计算机物理内存资源有限并且成本高昂，所以UOS的内存是付费使用的。 比如：baodaotulong购买了“3.491KB”的内存，已经使用了“3.49KB”的内存，那么他只有0.001KB的内存用来存放自己的某些数据了。 UOS的内存容量现为８G,这意味这每个UOS节点程序要求自己计算机的内存里面有８G的容量是用来存“常用的状数据”的。这些常用的包含合约本身，以及合约内部自定义的一些数据。 UOS的内存是根据bancor协议进行自动计费的。 公式如下：
得到的容量(Byte) = (当前剩余的容量 *付款的UOS)/(池中的UOS + 付款的UOS)
得到的UOS = (池中的UOS* 卖出的RAM) / (剩余的容量 ＋ 卖出的RAM)
内存资金池的初始值参数为500W,所以由第一个公式，当有500W的UOS入场内存时，池中的UOS为1000W，计算出：得到的容量= 总容量/2 = 4GB 。 接下来，详细价格如下表：
作图如下：
6.3.2 cpu和net
在考虑UOS资源的时候,要意识到UOS的节点是运行在真实计算机上的一个进程，并且每台这样的计算机运行的程序都是一致的，故UOS的资源并不因为节点的增加而增加。一个交易传输到UOS的出块节点，该节点会先执行这个交易，然后打包进区块。因此，UOS的cpu描述的是交易执行所需要的时间，net描述的是交易本身所占容量的大小。cpu和net是可再生资源，用户使用后，无论多少，都会随时间慢慢恢复，可用的总量与自己的抵押有关。 baodaotulong用户抵押了0.1000 UOS的cpu，已使用了 2.939ms，可用 2.122s，意味着baodaotulong在接下来的24小时内，如果发起交易，则这些交易的执行时间之和不能大于2.122s。 baodaotulong用户抵押了0.1000 UOS的net，已使用了432bytes，可用15.63MB，意味着baodaotulong在接下来的24小时内，如果发起交易，则这些交易的容量之和不能大于15.63MB。 我们可用用区块链浏览器查看交易消耗的cpu和net情况： https://explorer.uosio.org/transactions/5513440/366616970c7995a935e3263571bd543937a6512cc358c66a91ed449fbb0dcd21
"cpu_usage_us": 609 "net_usage_words": 16
cpu和net资源的平均使用量，是一种改进的指数移动平均模型：
其中: VX: 资源的平均使用量； VX’: 上次资源的平均使用量； unit: 本次交易消耗的资源量； Precision:精度补偿系数，防止unit过小出现整除为零； Windowsize:窗口大小； Futuredistance:上个更新时刻为周期起点，当前时刻离周期终点的距离。 当每个块都有更新时，Futuredistance+1 = Windowsize，上试退化成普通的指数平均模型。 当前的cpu更新使用量：
对某个用户而言，Windowsize的大小是24小时的区块数量。 而用户cpu和net资源的可用量与自身抵押和UOS的繁忙程度有关，UOS用虚拟资源的概念表述。UOS上的交易越多，UOS越繁忙，UOS的虚拟资源越少，用户可使用的资源就越少，用户抵押的越多，可使用的资源就越多。实际上，UOS区块的cpu和net的更新使用量计算公式也是依照以上两个公式，不过unit为一个区块总的cpu和net使用量，Windowsize为60。 下面的命令是查询UOS系统的全局参数，以cpu为例，当区块的cpu当前更新使用量小于target_block_cpu_usage_pct_max_block_cpu_usage，UOS会判定系统处于闲暇，抬升UOS的虚拟cpu大小。反之亦然，虚拟cpu的取值区间为[max_block_cpu_usage，max_block_cpu_usage_1000]。
6.4 多重签名
UOS的多重签名有两种方式：一种是手动多重签名，一种是利用uosio.msig合约进行多重签名。
6.4.1 手动多重签名
设置baodaotulong的账户的active权限为多公钥控制：
baodaotulong账户的组成如下：
发起一条转账交易,不广播，不签名(构造一个没有签名的交易json):
tr.json如下：
然后分别用avtive权限的两个私钥签名：
分别复制签名字段：
将tr.json的signatures字段用上面两个签名填充：
最后将交易发送到rpc节点：
会返回一个json，包含交易id:
41454b52b491f22468abbe8967df570a4961b63452cdb20743e65885b6bca7c0
6.4.2 调用uosio.msig合约的多重签名
使用uosio.misg合约合约同样达到多重签名的目的，但是多重签名合约只面向权限组成为账户的情况，手动多重签名则没有这个限制： 更改账户的额权限，便于测试：
查看权限：
baodaotulong的active权限阈值为２，需要bithumbshiny的active权限以及testertester的active权限才能解锁。
发起一个提案：baodaotulong往aaaaaaaaaaaa转0.001个UOS。
查看提案：
赞同提案，需要两个权限均赞同：
执行提案：
以上是对某一个合约执行发起提案，我们也可以对具体某一个交易发起提案，这要求我们先构造好一个交易json(见手动多重签名)：
6.5 共识主节点
共识主节点是UOS的出块节点和备用出块节点的统称，他们不仅仅提供UOS的出块以及验证，而且可以给其他ulord侧链提供共识服务，普通账户如果自己给自己抵押的cpu和net之和大于100000UOS,则可以申请成为活跃的出块用户，得票最多的前21位用户将有资格出块。将某个"活跃的出块用户"以及他在计算机上运行的UOS进程合称为一个共识主节点。 申请成为共识主节点：
producer_key是出块公钥，用来打包块的时候签名，他的私钥不需要存放在钱包里。 共识主节点列表的查看命令为：
共识主节点的状态如下，需要uosio权限即是需要主节点发起提案，经由2/3投票通过。
BP状态
需要权限
可否撤回抵押
可否出块
可否提奖
可否更改为其他状态
active
bp自己
否
可
可
可
release
uosio
可
否
否
可
remove
uosio
抵押扣除
否
否
否
共识节点的奖池有三个：uosio.bvpay、uosio.bpay 、uosio.vpay 他们之间的关系是，uosio.bvpay是奖池源头，uosio.bpay是出块奖池，uosio.vpay是投票奖池。
uosio.bvpay奖池源奖金的0.8将会进入出块奖池，奖池源的0.2将会进入投票奖池。 查看总奖池：
id = 0代表当前奖励周期，id = 1代表下一次奖励周期，周期长度为30天。 假如现在的时间戳在周期０内，那么bp发起一次领奖，能领取多少钱呢？ 假设为领取时刻为ｔ,则奖池源发放的奖金为：
out_all = (t - laster_line_0) *quantity_0* 10000 / (dead_line_0 - laster_line_0); (6-5-1)
奖金会分为两部分流入uosio.bpay与uosio.vpay。其中，0.8*out_all 进入uosio.bpay,0.2进入uosio.vpay。 查看系统合约global参数：
里面有4个参数与奖励有关
下面查看bp的具体情况，以“uoskkkkonebp”为例:
uoskkkkonebp的获得票数为1000000000.00000000000000000，未结算的生产区块数量为7385，最后一次领取奖励的时间戳为：1554259259000000 那么如果ｔ时刻(t > 1554259259000000 + 3600) uoskkkkonebp能领取出块的奖励为m,则:
m = (out_all*0.8 + perblock_bucket)*unpaid_blocks / total_unpaid_blocks (6-5-2)
uoskkkkonebp能领取的投票奖励为n,则:
n= (out_all*0.2 + pervote_bucket)*total_votes / total_producer_vote_weight (6-5-3)
注：当n >= 100 0000时，即投票奖励大于100UOS,n才有效,否则不会发放投票奖励
uoskkkkonebp能够领取的总奖励为：m+n ,由(6-5-1)、(6-5-2)、(6-5-3)式可算出，注意最后得到的单位是“分”，要转化为"元",需要除以10000.
Last updated
Was this helpful?