eos开发者日志2017 07-9
原文地址:https://steemit.com/eos/@dan/eos-developer-s-log-stardate-201707-9
今天我想花点时间解释一下当前eos.io转账的结构,以便开发者能更好地理解货币模型。下面是一个转账信息的json文件,这是sam转账给alice的信息。在这个例子中,货币(currency),sam,alice是帐号名称,但是将会以不同的方式使用这些账号。
{
"refBlockNum": "12",
"refBlockPrefix": "2792049106",
"expiration": "2015-05-15T14:29:01",
"scope": [
"alice",
"sam"
],
"messages": [
{
"code": "currency",
"type": "transfer",
"recipients": [
"sam",
"alice"
],
"authorization": [
{
"account": "sam",
"permission": "active"
}
],
"data": "a34a59dcc8000000c9251a0000000000501a00000000000008454f53000000000568656c6c6f"
}
],
"signatures": []
}
当使用签名把这些信息序列化为二进制的时候,这个转账信息的大小大概160 byte,比steem的转账信息略大一些,steem的转账信息大小大概120 byte,bitshares的转账信息的大小 大概94 byte。之所以数据变大了,是因为包含了一些特定的收据,验证和范围信息,这些信息大约51 byte。
把转账当作权益证明(TaPoS - Transactions as Proof of Stake)
熟悉steem 和bitshares的人可能会认出这个转账信息的头三个字段;它们都是一样的。这些字段被TaPoS(把转账当作权益证明Transactions as Proof of Stake)使用,确保只能在引用区块之后和到期之前计入转账信息。
scope
下一个字段"scope",是新加入eos.io的,用于指定读取或写入的数据的范围。如果一条消息尝试在范围之外读或写数据,那么这个交易就会失败。我们可以并行地处理交易,只要在它们的范围内没有重叠。
eos.io软件的一项关键创新是scope 和 代码(code)是两个完全分开的概念。你可以看到即使我们使用货币合约的代码(code)来执行转账,货币合约也不会涉及到scope。
消息
一次转账可以包含一条或多条按次序并自动申请的消息(要么全部成功要么全部失败)。在本例中只有一条消息,让我们仔细看看:
代码:
每条消息必须指定它要执行的代码,在本例中,货币合约的代码将会调用下面的方法:
currency::apply_currency_transfer(data)
类型:
类型(type)字段定义了消息的类型(并隐式地指定了数据data的格式)。从面向对象的角度来看的话,你可以把type看作“currency”类上的“name”方法。在本例中,类型是“transfer”
${namespace}::apply_${code}_${type}( data )
本例中,“namespace”是货币合约,当然,方法apply_currency_transfer 也可以在其它的命名空间(namespace)中被使用。
接收者:
除了调用currency::apply_currency_transfer(data)之外,方法apply_currency_transfer(data)也会被每条收据调用。比如,下面的方法会以这种次序顺序调用:
currency::apply_currency_transfer(data)
alice::apply_currency_transfer(data)
sam::apply_currency_transfer(data)
account::标记了实现这个方法的合约。alice 和sam可以选择不实现这个方法,如果当currency::apply_currency_transfer被执行的时候,它们没有什么特别的逻辑需要执行的话。然而,如果sam是一个交易所,那么sam在货币转账生成的时候,它可能会去处理存款与提款。
生成这笔转账的人可以添加任意数量的接收者。而且某些合约可以要求一定要通知合约的某些参与方。
在currency这个例子中,发送者和接收者都必须通知。你可以在这查看它们是如何被指定的。
void apply_currency_transfer() {
const auto& transfer = currentMessage<Transfer>();
requireNotice( transfer.to, transfer.from );
...
}
验证
每条消息都可以对一个或多个帐号要求验证。在steem和bitshares中,验证是基于消息类型隐式定义的;但是在eos.io,消息必须显示地定义提供的验证。eos.io系统会自动的验证,此交易是否已被所需要的所有签名所签署,以此授予特定的权限。
在本例中,消息表明了它必须被sam的活动授权层级(active permission level)签署。合约代码将验证sam的授权是否已提供。你可以在这个示例中查看验证。
void apply_currency_transfer() {
const auto& transfer = currentMessage<Transfer>();
requireNotice( transfer.to, transfer.from );
requireAuth( transfer.from );
...
}
数据:
每个合约都可以定义它自己的数据格式。不使用abi的话,这些数据只能被转换为十六进制数据;然而,货币合约定义了数据的格式为transfer结构:
struct Transfer {
AccountName from;
AccountName to;
uint64_t amount = 0;
};
根据这个定义,我们可以把那些二进制数据转换为类似下面的这种数据:
{ "from" : "sam", "to": "alice", "amount": 100 }
调度
现在我们理解了eos.io转账的结构,我们就可以看看eos.io区块的结构了。每个区块会被分成环(cycle),环都是顺序执行的。在每个环的内部,可以有任意数量的并行执行的线程。这么做的奥妙在于可以确保线程包含的转账的范围不会交叉。如果一个环内的线程之间存在范围(scope)重叠的话,不需要额外的数据处理就能把该区块声明为无效的。
结论
并行执行的最大挑战在于确保同一数据不会被两个线程同时获取。与传统并行编程不同的是,我们不太可能使用锁来限制读取,因为这么做会增加不确定性,而且可能会打破共识。即使能使用锁,我们也不太愿意使用,因为频繁使用锁可能会降低性能。
一种替代的方法是,与其在获取数据的时候使用锁,不如在调度执行的时候使用锁。从这个角度来看,scope字段定义了转账想要加锁的账号。调度者(区块生产者)确保线程不会同时获取同一个锁。使用这种转账结构和调度机制,才能解决内存获取冲突以及提高并行执行的机会。
与其它平台不同,把代码(货币合约)从数据(账号存储)中分离开来,使得锁的分离成为可能。如果货币合约和它的数据是绑定的,那么每次转账就必须给货币合约上锁,那么所有的转账将会被单线程的吞吐量所限制。但是由于转账消息只需要在发送者和接收者的数据上锁,那么货币合约将不再是瓶颈。
对于交易所合约来说,货币合约是不是瓶颈就尤其重要。每次交易所取款或提款时,货币合约和交易所合约都会被强制并入一个线程。如果频繁地使用这两个合约,那么就会降低所有货币和所有交易所用户的性能。
在eos.io模式下,两个用户间可以自由转账,而不需要担心其它账号/合约的顺序(单线程的)吞吐量。
👍
@peterchen145 got you a $3.62 @minnowbooster upgoat, nice! (Image: pixabay.com)
Want a boost? Click here to read more!