Lisk智能合约并没有那么智能。作为一名区块链开发者，当我读 到Lisk的营销资料时，我是很兴奋的。完全由JavaScript 驱动的区块链概念和智能合约平台，这是我一直想要去建立的东西。我一直没去做这个事情，因为它所涉及的复杂性，在时间和预算上已超出了我的承受能力。
（图：比特股创始人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) )第二步 —— 定义一个数据库和指数
这一步比起使用标准的Boost多指数包含库（Boost Multi Index Containers）而言，谈不上更复杂。这些包含库的性能，要好于任何带有类似指数的SQL数据库。在这种情况下，我们建立一个强大的索引，它可以很容易地按照它们接收或发出的顺序来请求信息。这使得每一位用户都能使用“收件箱”和“发件箱”功能。
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,
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,
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给出的例子要更健壮及简洁。特别当你注意到以下这几点时：
应用开发者并没有实现任何的撤销功能。
应用开发者不必担心费用的问题。
应用开发者不必对确认和未确认之间的区别感到担心。
应用开发者不必担心序列化的问题。
代码可以更简短。
而Steem区块链能够自动处理这些复杂的问题，开发者还必须注意到一点，他们的实施并不会创建一个无限循环、内存泄漏或产生不确定性的行为。幸运 的是，当需要确定性的行为时，C++是更容易开发的。而使用很多常见的JavaScript语言特征，其结果会隐藏不确定性的行为。
Lisk其中一个智能合约概念是使用了侧链。Lisk 智能合约不能持有资金，因为验证节点不会执行代码。Lisk依靠第三方多重签名解决方案来评估代码，并授权交易。
使用STEEM和比特股，开发人员可通过同样的方式来实现智能合约。主要的区别就是使用了C++语言，而非JavaScript。Steem拥有着 一个主要的优势，它是其他智能合约平台所没有的：免费的交易。这意味着，任何人都可以实施一个侧链“智能合约插件”，而不必担心合约所要求的费用问题。
过去我曾提出了很多以太坊的问题，但相比于 Lisk来说，我觉得以太坊可以称得上是开发者的天堂了。以太坊帮助开发者解决了很多问题，而它们曾困扰了很多有经验的区块链开发者。相比于学习数百万种 如何避免自砸双脚的方式，掌握一种新语言的语法是微不足道的。以太坊应用 , 不会产生不确定性的行为。
区块链技术不断在向前迈进，Lisk团队也刚融到了一大笔钱，可以用于推进这个平台。Lisk所面临的大多数问题，都可以通过一个高度定制的JavaScript 环境解决。
目前，Lisk与其目标之间的差距是巨大的。如果他们能够解决掉我所提出的问题，那么有一天，他们的平台就能够为以太坊带来一些竞争压力。对于 Lisk的初学者而言，它的架构的扩展比以太坊会更好，而使用JavaScript是一个主要的优势。想要将Lisk，从目前的状态发展成以太坊真正的竞 争者，这可能会要耗尽团体融到的钱，甚至还会更多。
如果你认为Lisk是一个由JavaScript语言驱动的智能合约平台，那么你应该考虑STEEM会是它的重要竞争对手，其能力比目前的Lisk要强。如果你不认为 Steem是一个通用的智能合约平台，那么很显然，以太坊仍是这个领域里唯一的游戏。
声明：此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。本网站所提供的信息，只供参考之用。
