BTC.com手机客户端

比特股创始人:Lisk智能合约并不智能,远不及以太坊

洒脱喜 发布在 竞争币 3 7339

Lisk智能合约并没有那么智能。作为一名区块链开发者,当我读到Lisk的营销资料时,我是很兴奋的。完全由JavaScript 驱动的区块链概念和智能合约平台,这是我一直想要去建立的东西。我一直没去做这个事情,因为它所涉及的复杂性,在时间和预算上已超出了我的承受能力。

dan

(图:比特股创始人Daniel Larimer)

 

智能合约平台的目的

 

开发区块链技术是具有挑战性的,因为你需要确保你的软件是以确定的方式进行的,并且它能从任何错误当中恢复而不会留下任何不必要的副作用。有时简单如使用浮点数的数学运算,也会导致产生非确定性的行为,并带来损失。

当设计一个智能合约平台的时候,我会期待能够给开发者提供以下这些工具:

  1. 错误事件的自动回滚;
  2. 不能产生非确定性的代码;
  3. 防止无限循环或者测量总计算的能力;
  4. 防止无限制的内存增长或测量内存消耗的能力;

令我感动震惊的是,上述的列出的问题,Lisk一个也没能解决。他们的“沙箱”(sandbox),不能用于运行不受信任的代码,他们的理论框架没有对不确定性行为提供任何的保护,也没有办法来衡量或限制资源使用,他们甚至没有提供确保错误能被正确回滚的工具。

 

情况有多糟糕?

 

我决定去查看一下Lisk的例子“应用”,而第一个例子,就是一个简单的信息应用。这个应用的目的,是让人们通过区块链来给他人发送信息。如果作为一名Lisk开发者,我会希望做到以下这几点:

  1. 定义消息并进行编序化操作;
  2. 手动处理请求和撤消对数据库的更改;
  3. 手动解决区块链余额的更改;
  4. 手动处理“确认”和“未经确认”的状态;

Lisk

正如你在这里可以看到的,Lisk几乎没有为开发者提供任何的帮助。事实上,它提供给开发者的API是过于复杂的,这让我想起了早期的比特股1.0的框架。在比特股1.0当中,我们发现其框架放缓了项目的发展,并且其出错率是令人难以置信的。

 

Lisk vs非智能合约平台

 

我最近为“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,
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的例子比Lisk给出的例子要更健壮及简洁。特别当你注意到以下这几点时:

  1. 应用开发者并没有实现任何的撤销功能。
  2. 应用开发者不必担心费用的问题。
  3. 应用开发者不必对确认和未确认之间的区别感到担心。
  4. 应用开发者不必担心序列化的问题。
  5. 代码可以更简短。

 

Lisk侧链

 

Lisk其中一个智能合约概念是使用了侧链。Lisk依靠第三方多重签名解决方案来评估代码,并授权交易。

使用STEEM和比特股,开发人员可通过同样的方式来实现智能合约。主要的区别就是它俩使用的是C++语言,而不是JavaScript。Steem拥有着一个主要的优势,这在其他智能合约平台上是没有的:免费的交易。这意味着,任何人都可以实施一个侧链“智能合约插件”,而不必担心合约所要求的费用问题。

 

以太坊是更高级的

 

过去我曾提出了很多以太坊的问题,但相比于 Lisk来说,我觉得以太坊可以称得上是开发者的天堂了。以太坊帮助开发者解决了很多问题,而它们曾困扰了很多有经验的区块链开发者。相比于学习数百万种如何避免自砸双脚的方式,掌握一种新语言的语法是微不足道的。此外,以太坊应用 , 不会产生不确定性的行为。

 

向前发展

 

区块链技术不断在向前迈进,Lisk团队也刚融到了一大笔钱,可以用于推进这个平台。Lisk所面临的大多数问题,都可以通过一个高度定制的JavaScript 环境来解决。

目前,Lisk与其目标之间的差距是巨大的。如果他们能够解决掉我所提出的问题,那么有一天,他们的平台就能够为以太坊带来一些竞争压力。对于 Lisk的初学者而言,它的架构扩展比以太坊会更好,而使用JavaScript是一个主要的优势。想要将Lisk从目前的状态发展成以太坊真正的竞争者,这可能会要耗尽该团体融到的钱,甚至还会更多。

 

结论

 

如果你认为Lisk是一个由JavaScript语言驱动的智能合约平台,那么你应该考虑STEEM会是它的重要竞争对手,其能力比目前的Lisk要强。如果你不认为 Steem是一个通用的智能合约平台,那么很显然,以太坊仍是这个领域里唯一的游戏。

发文时比特币标准价格 买价:¥3577.3 卖价:¥3575.31
原文:https://steemit.com/lisk/@dan/why-lisk-is-inferior-to-ethereum
作者: Daniel Larimer
编译:洒脱喜
稿源(译):巴比特资讯(http://www.8btc.com/lisk-is-inferior-to-ethereum)
版权声明: by nc" sa 作者保留权利。文章为作者独立观点,不代表巴比特立场。

评论:3

您需要登录后才可以回复 登录|注册
    区块链狂魔
    区块链狂魔 189 天前

    lisk就是一坨屎[doge],但是它能赚钱,那这坨屎也是香的

    +1
    +1
    我要点评
    Author Image
    叶良辰 189 天前

    说的好像比特股有多好似的,典型50步笑100步

    +1
    +1
    我要点评
    巴比特资讯
    巴比特资讯 189 天前

    【比特股创始人:Lisk智能合约并不智能,远不及以太坊】Daniel Larimer:过去我曾提出了很多以太坊的问题,但相比于 Lisk来说,我觉得以太坊可以称得上是开发者的天堂了。http://t.cn/R54Jx89

    +1
    +1
    我要点评