(图:比特股创始人Daniel Larimer)
开发区块链技术是具有挑战性的,因为你需要确保你的软件是以确定的方式进行的,并且它能从任何错误当中恢复而不会留下任何不必要的副作用。有时简单如使用浮点数的数学运算,也会导致产生非确定性的行为,并带来损失。
当设计一个智能合约平台的时候,我会期待能够给开发者提供以下这些工具:
-
错误事件的自动回滚;
-
不能产生非确定性的代码;
-
防止无限循环或者测量总计算的能力;
-
防止无限制的内存增长或测量内存消耗的能力;
令我感到震惊的是,上述的列出的问题,Lisk一个也没能解决。他们的“沙箱”(sandbox),不能用于运行不受信任的代码,他们的理论框架没有对不确定性行为提供任何的保护,也没有办法来衡量或限制资源使用,他们甚至没有提供确保错误能被正确回滚的工具。
我决定去查看一下Lisk的例子“应用”,而第一个例子,就是一个简单的信息应用。这个应用的目的,是让人们通过区块链来给他人发送信息。如果作为一名Lisk开发者,我会希望做到以下这几点:
-
定义消息并进行编序化操作;
-
手动处理请求和撤消对数据库的更改;
-
手动解决区块链余额的更改;
-
手动处理“确认”和“未经确认”的状态;
正如你在这里可以看到的,Lisk几乎没有为开发者提供任何的帮助。事实上,它提供给开发者的API是过于复杂的,这让我想起了早期的比特股1.0的框架。在比特股1.0当中,我们发现其框架放缓了项目的发展,并且其出错率是令人难以置信的。
我最近为“Steem”实施了一个类似的消息应用(又名插件),Steem甚至还称不上是一个智能合约平台!但我的信息插件比 Lisk的应用要略为强大和复杂。所以,我将在下面展示一个简化的版本。如果你读不懂这些代码,不要担心,你读下解释就行。
第1步 – 定义消息
struct private_message {
string from;
string to;
string message;
};
FC_REFLECT( private_message, (from)(to)(message) )
第二步 —— 定义一个数据库和index函数
这一步比起使用标准的Boost多index函数包含库(Boost Multi Index Containers)而言,谈不上更复杂。这些包含库的性能,要好于任何带有类似index函数的SQL数据库。在这种情况下,我们建立一个强大的index函数,它可以很容易地按照它们接收或发出的顺序来请求信息。这使得每一位用户都能使用“收件箱”和“发件箱”功能。
struct message_object {
time_point received;
string from;
string to;
string message;
};
FC_REFLECT_DERIVED ( message_object, (db::object), (received)(from)(to)(message) )
struct by_to_date;
struct by_from_date;
struct by_id;
typedef multi_index_container<
message_object,
indexed_by<
ordered_unique< tag< by_id >, member< object, object_id_type, &object::id > >,
ordered_unique< tag< by_to_date >,
composite_key< message_object,
member< message_object, string, &message_object::to >,
member< message_object, time_point, &message_object::receive_time >,
member<object, object_id_type, &object::id >
>,
composite_key_compare< less<string>,
greater< time_point >,
less< object_id_type > >
>,
ordered_unique< tag< by_from_date >,
composite_key< message_object,
member< message_object, string, &message_object::from >,
member< message_object, time_point, &message_object::receive_time >,
member<object, object_id_type, &object::id >
>,
composite_key_compare< less<string>,
greater< time_point >,
less< object_id_type > >
>
>
> message_multi_index_type;
typedef generic_index< message_object, message_multi_index_type> private_message_index;
第三步 - 定义一个API
定义一个API,其目的是允许第三方能够检查你的应用状态。在这个例子当中,我们需要两个API调用,一个是负责收件箱,另一个负责发件箱。
class private_message_api : public std::enable_shared_from_this<private_message_api> {
public:
typedef vector<message_object> messages;
private_message_api(const app::api_context& ctx):_app(&ctx.app){}
messages get_inbox( string to, time_point newest, uint16_t limit )const;
messages get_outbox( string from, time_point newest, uint16_t limit )const;
private:
app::application* _app = nullptr;
};
第四步 - 实现消息处理程序
该方法的目的,是当每一个私有信息(private_message)操作被包含在区块链时,就对状态进行更新处理。该消息处理程序,负责验证消息是被发送者签名过的,如果是这样的,就将该信息添加到数据库当中。
void private_message_plugin::on_operation( const operation_object& op_obj ) {
if( op_obj.op.which() == operation::tag<custom_json_operation>::value ) {
const custom_json_operation& cop = op_obj.op.get<custom_json_operation>();
if( cop.id == “private_message” ) {
auto message = json::from_string(cop.json).as<private_message_operation>();
FC_ASSERT( cop.requires_auth(message.from),”sender didn’t sign message” );
db.create<message_object>( [&]( message_object& pmo ) {
pmo.from = pm.from;
pmo.to = pm.to;
pmo.message = pm.message;
pmo.receive_time = db.head_block_time();
});
}
}
}
第五步 - 实现API
通过JSON RPC,这个API是可访问steemd 进程的。除了使用了替代指示by_from_date,而不是by_to_date,这个get_outbox API几乎是相同的。
messages private_message_api::get_inbox( string to,
time_point newest,
uint16_t limit )const
{
const auto& pmi = db.get_index_type<private_message_index>();
const auto& idx = pmi.indices().get<by_to_date>();
messages result;
auto itr = idx.lower_bound( make_tuple( to, newest ) );
while( itr != idx.end() && limit && itr->to == to ) {
result.push_back(*itr);
++itr; –limit;
}
return result;
}
对于这个特定的信息应用,Steem的例子比Lisk给出的例子要更健壮及简洁。特别当你注意到以下这几点时:
-
应用开发者并没有实现任何的撤销功能。
-
应用开发者不必担心费用的问题。
-
应用开发者不必对确认和未确认之间的区别感到担心。
-
应用开发者不必担心序列化的问题。
-
代码可以更简短。
Lisk其中一个智能合约概念是使用了侧链。Lisk依靠第三方多重签名解决方案来评估代码,并授权交易。
使用STEEM和比特股,开发人员可通过同样的方式来实现智能合约。主要的区别就是它俩使用的是C++语言,而不是JavaScript。Steem拥有着一个主要的优势,这在其他智能合约平台上是没有的:免费的交易。这意味着,任何人都可以实施一个侧链“智能合约插件”,而不必担心合约所要求的费用问题。
过去我曾提出了很多以太坊的问题,但相比于 Lisk来说,我觉得以太坊可以称得上是开发者的天堂了。以太坊帮助开发者解决了很多问题,而它们曾困扰了很多有经验的区块链开发者。相比于学习数百万种如何避免自砸双脚的方式,掌握一种新语言的语法是微不足道的。此外,以太坊应用 , 不会产生不确定性的行为。
区块链技术不断在向前迈进,Lisk团队也刚融到了一大笔钱,可以用于推进这个平台。Lisk所面临的大多数问题,都可以通过一个高度定制的JavaScript 环境来解决。
目前,Lisk与其目标之间的差距是巨大的。如果他们能够解决掉我所提出的问题,那么有一天,他们的平台就能够为以太坊带来一些竞争压力。对于 Lisk的初学者而言,它的架构扩展比以太坊会更好,而使用JavaScript是一个主要的优势。想要将Lisk从目前的状态发展成以太坊真正的竞争者,这可能会要耗尽该团体融到的钱,甚至还会更多。
如果你认为Lisk是一个由JavaScript语言驱动的智能合约平台,那么你应该考虑STEEM会是它的重要竞争对手,其能力比目前的Lisk要强。如果你不认为 Steem是一个通用的智能合约平台,那么很显然,以太坊仍是这个领域里唯一的游戏。
发文时比特币标准价格 买价:¥3577.3 卖价:¥3575.31 (来源:HaoBTC,简洁优雅的比特币交易所)
原文:https://steemit.com/lisk/@dan/why-lisk-is-inferior-to-ethereum
作者: Daniel Larimer
编译:洒脱喜
稿源(译):巴比特资讯(http://www.8btc.com/lisk-is-inferior-to-ethereum)
文章为作者独立观点,不代表巴比特立场。
巴比特官方千人Q群:81153017
关注本微信号,回复“区块链报告”即可免费获取20份国内证券行业发布的区块链研究报告
2016区块链国际峰会将于2016年6月22-24日在中国北京隆重召开。本次峰会将有超过500位业内高层参与,汇聚了证券交易所、基金行业、支付及转账、银行业、保险行业、网络安全、电子商务、物联网、加密数字股权众筹、P2P征信、医疗信息、物联网和云计算等行业。本次会议由亚洲区块链DACA协会主办,巴比特区块链研究中心协办,上海博勘商务咨询有限公司承办。点击”阅读原文“直达巴比特报名优惠通道(VIP全程参会证比现场注册价优惠3000元,普通参会证优惠1800元)