认知干货长文，共五小章，建议收藏后阅读。

前言。

爱情是生活的“奢侈品”。

那什么是奢侈品？你可能会想到Lv，Gucci，Dior。

但那只是奢侈品品牌。

要搞懂爱情，首先，我们需要达成对奢侈品的共识。

以及，凭什么，爱情就成了奢侈品？

一、什么是奢侈品？

清晰地定义概念，是精准认识事物的关键。

所以，先聊聊什么是奢侈品？

在《奢侈品经济学》里，全球最大的奢侈品集团，路威酩轩（LVMH）总裁阿尔诺，说得非常精准。

阿尔诺说：奢侈品，是非凡之人的日常，是平凡之人的的非凡。

换言之，爱情这个“奢侈品”，是平凡之人的非凡。

这一点，在五条人乐队的歌词中也有体现：

虽然说人生并没有什么意义，但是爱情确实让生活更加美丽。——《阿珍爱上了阿强》

****当阿珍爱上阿强，物质生活也许并没有因此变得更好，但是确实让生活变得更加美丽了。

人天然就会追求美。

不过，这种美丽，这种平凡之人的非凡，还是很奢侈的。

为什么呢？

二、为什么爱情是生活的奢侈品？

奢侈品最明显的特征，当然是贵了。

实际上，这不是最明显的特征，奢侈品真正的代名词是：

**「我有钱」**我拥有奢侈品，我有很强的消费能力。

**「我很美」**我使用奢侈品，我很有时尚的审美能力。

**「我有思想」**我穿戴奢侈品，我用时尚和艺术表达我的价值观。

说到底，我们渴望奢侈品，是渴望非凡的身份认同，渴望美好工艺品背后带给我们的情绪化体验。

当你看到我穿上一件LV衣服，或者背上LV包包，你会感觉到，我有一点特别。

爱情也一样。

爱情的奢侈，在于与对方的亲密存在，会让自己感到美好的情绪化体验。

爱情的奢侈，是让自己感觉到，在千万人海中「我有一点特别」。

两个人，在阳光下手牵手逛街，在庆祝节日的烛光晚餐相视，在翻云覆雨后的深夜拥吻睡去。

友情，亲情都难以得到爱情这种「我有一点特别」的美好的情绪化体验。

可是，一切事物皆有其代价。

买包，奢侈品品牌要你付几万块。爱情也有其代价。

诚如鲁迅在杂文中，谈及对爱情的理解：

如果一个人没有能力帮助他所爱的人，最好不要随便谈什么爱与不爱。

当然，帮助不等于爱情，但爱情一定包括帮助。
答案很清楚了。

**谈爱、谈恋爱、谈爱情、谈亲密关系，**需要你有能力帮助你所爱的人。

知道爱情的代价后，我们该怎么做？

三、如何对待爱情这种“奢侈品”？

我们人类，其实很普通了。

特别在中国，人一多，就更不起眼了。

所以我们才会去买各种各种的东西，追求个性，追求独特，追求被细致照顾的服务，追求爱。

而人类作为聪明一点的哺乳动物，终其一生也只有两个使命：生存和繁衍。

所谓，爱情、择偶、交配、生子和育儿，也都是本能。遵循直觉就好，不会太费力气。

只是男人和女人的策略不太一样而已。

爱情，还是很值得渴望、追求、拥有和珍惜的。虽然很贵，代价很大。

爱情，那只是婚姻、繁衍使命的前戏。

在此之前，好好努力完成生存、生活、发展这个使命任务。

电影《超体》里面有一句话：生命，要么选择永生，要么选择繁衍。

所以，生存是为了繁衍。而繁衍，是为了传承。

这是深层次的，生命层面的，爱情的意义：传承。

回归日常，回到朴素。

落到实处，落到你我这一个个人身上，爱情的意义无非是让自己感觉好一点，让自己感觉「我有一点特别」。

说实话，爱情其实是个特别大的人生课题。其中涉及亲密关系、家庭、原生家庭模式投射、价值观、社交智慧、自尊等等。

加上每个人的爱情观建立在经验和价值观之上，而每个人的价值观又不尽相同。

于是，建议这东西，往往是我之蜜糖，彼之砒霜。

但我还是斗胆，给男人们和女人们分别给出几条行动指南。

希望给出一点**「两性合作更多博弈更少」**良性方向，供你参考。

指南分为两部分，男人的行动指南和女人的行动指南。

四、男人的行动指南

1.校园时期，不影响学习的前提下，多谈恋爱，认识女人，学习爱情。

谈恋爱是门手艺，光学不练假把式。

男人的经验丰富是女人不承认但渴望的东西，「前人种树，后人乘凉」，女人都希望作为后者进入感情。

而且，出了校园，建立爱情关系的规则就变得天翻地覆了。请珍惜校园时期，单纯美好的恋爱关系。

推荐阅读冯唐的**《三十六大》**，能从基础认知开始，学习作为男人如何对待女人。

2.全心全意的爱自己，而后有足够的爱扛起关系中的责任。

自己爱自己，自己尊重自己，自己崇拜自己，自己对自己最好，自己对自己的所作所为骄傲自豪，自己都想跟自己谈恋爱。

当你爱的能量是满到溢出来，当你自恋到顶，你才应该进入恋爱关系。

这时，你才会吸引来对的人，你也有能力建立正确逻辑的感情。

这一点很重要。

（回顾上文鲁迅对爱情的理解“如果一个人没有能力帮助他所爱的人，不要随便谈什么爱与不爱”）

3.学会尊重自己。

这一点，不止用于爱情，也适用于所有关系。也是作为男人最重要的一点。也是做男人最朴素的一点。

因为很多女人会被教导尊重自己。而身份一旦换成男人，就没有人去强调这一点。仿佛他们天生就会。这不对。

尊重自己的意思是：

不当舔狗，不委屈自己，不以牺牲自己的利益为代价利她。

****在亲密关系中，有言语或行为让自己不舒服，有基本的勇气和原则去拒绝和远离，甚至斩断关系。

****不当渣男，不伤害对方和自己。

和获得财富一样，建立关系和长期主义高度相关，和人品高度相关。建立短期或长期亲密关系，不影响你保持正直的道德品质。

五、女人的行动指南

1.认真学习性知识，做爱时让男人戴安全套。

安全套，是安全享受性爱的前提，也是性爱领域最伟大的发明之一。

无论年龄是18，还是30+，女人学习性知识的好处都大于男人。

做爱，女人的好处是比男人大。

女人在性爱中的刺激和享受，是男人的好几倍。学好性知识，不会再羞耻，而且尽情享受性快乐，还有机会安全解锁性爱的新模式。

做爱，女人的坏处也是比男人大的。

不戴套，意外怀孕吃紧急避孕药或生下无辜的小孩，伤害的是女人的身体，对男人来说只有道德谴责和法律规定养育责任。

学好性知识，认知上重视，让男人戴套不心软，才是强效避孕和爱惜自己，也更安心享受性快乐。

建议从**《给爸爸妈妈的儿童性教育指导书》**开始学习，真正从零开始，补齐0-6岁的性知识基础。

2.早期多谈恋爱，建立健康的感情价值观。

如何挑选男人，女人在这一点上有本能优势，用不着我教。

即使如此，女人仍然是情绪动物，这是女人独有的天赋。

但是，也更容易受情绪影响，犯错不自知。

这是为什么，各大服装品牌和化妆品集团的主要客户群体，都是女性的原因。

这是事实，无可厚非。谈恋爱和买东西不同，挑到不适合的商品，顶多损失钱财，但是如果因为恋爱脑上头，挑到不合适的恋爱对象，伤财劳民还伤心。

这一点上，女人同样需要经验去认识男人，筛选男人和学会正确的与男人相处。

早期（12岁+）情窦初开，就要学习谈恋爱了。要学习在不同阶段，设置并捍卫合适的相处底线。

另一方面。

在正常男人视角去看，找对象最核心的一点需求：其实是找三观正常的女人，这种朴素的需求。

而这一点品质，在现在的社会舆论下，显得十分稀缺。（正常男人也很稀缺）

**当女人学会健康的情感价值观，能增加核心择偶竞争力。**也为自己扩大了择偶选项。

3.学习女人视角下，健康的感情价值观

（1）爱自己，爱对方，对对方好，会为对方考虑。
（2）情绪稳定，愿意在关系中磨合和调整自己。
（3）有基本的社交直觉，能体面的应对各种社交场合。
（4）照顾家庭，养育下一代。

关于爱情，就聊到这，余不一一。

如果有和您想法相悖的地方，就是您对。

如果你正在拥有爱情这件“奢侈品”，好好珍惜和保养。

如果暂时没有，祝你未来能建立健康的亲密关系，享受恋爱，让自己的生活更加美丽。

更多好文

改变自己：心理健康的自我训练

讲好一个关于自己的故事

自我关怀的4件小事｜心灵篇

下篇：五种功德门

十一、一者近门——得生安乐世界

7、一念周圆贯穿始终，依正归命全体礼拜

弟子：师父讲过相尽性显、自显自解脱。《金刚经》中说：“若见诸相非相，即见如来。”《圆觉经》上说：“知幻即离，不假方便，离幻即觉，亦无渐次。”那么用无对心念佛、用清净心念佛、用休息心念佛就是五果门？

师：这是果的一角。因为佛的果地觉是大圆满的，即周遍圆满。我们若染著于清净，是清净一角；若染著于平等，是平等一角。这个地方不能堕，一染著就会堕入世俗。

我们的染堕十分厉害，比如有的人为了清净心念佛，就染著于清净心，别人和他说话，他说不要烦我，我在念佛，我这么清净！有的人打坐感到清净，别人说上殿，他说去，不要烦人！染堕！我们一旦染上，无论染上的是清净还是圆满，染著这个名言就会落入事相，落入事相就会堕入世俗所谓自身心安乐，就是障菩提门。

这个染堕一定要注意。**你提的这些角度也是一种法执。****我们怎么念？****真正的休息，不是名言的休息。念佛，真正的无染，不是名言的无染。名言的无染，若名言是实相，名言也可以。**不要把它当成一种执著，染上这种东西，然后堕入世俗，障我们的菩提道业。

弟子：是不是在每一个起心动念或现行中觉悟、印契，就是即心即是？

师：这有混淆的地方，**这样提给人压力比较大，可能就被文字困住了。这个一念，可以很简单的理解，一念就是贯穿始终的一个愿望、一个愿、一个愿心、一个愿行、一个愿的得，或者说一个愿的果，都可以。**要是把这一念当成贯穿始终的意思，就简单了。**一现行启发一切现行，这是最重要的修行方便。**以一现行，比如我们现在这一念，贯穿于我们未来的相续念中，这一念就为方便。

若是一念一念地砍断：这一念、下一念，念念相续。这样的念不是不行，但可能是一种渐次修行状态。若是以这一念，愿心、愿行、愿果，令其贯穿于我们作为始终，贯穿于我们从现行开始，乃至相续未来，乃至洗涤你对过去的回忆，这一念是有意义的。一念三世，这一念是贯穿现行的一念，就来得安乐，来得实在，也究竟，有意义。这个地方希望审思，这一念是贯穿始终的修法，不是把它砍成一段一段的。

我们一般的作为会一段一段地来，一段一段地来人心就起伏变化了。说一段一段地来，就是我们凡夫的分别、割裂的心。果地觉的心，果地觉周遍。果地觉是周遍的，周遍圆满的。这一念就很方便。我们现在学的这个果地觉的教法，这个果地的认知一定要十分地清晰。把我们分别、割裂、前后、过去、未来、现在这样的思维习惯化作一念，善始善终，始终如一的这样一个愿、这样一个果、这样一个力量摄化于此。说佛力住持即得不退，这个佛力实际就是一念贯穿于始终。

弟子：净土平等缘起，为什么还有即心即是与心作心是的根性差别？

师：那不是根性。**即心即是、佛力不可思议、心作心是，这三者是蕅益大师为了使有情接触教法而给的进趣方便。**畅佛普度本怀皆是其平等缘起。佛果地觉、众生心、善知识心、我们的接受方法——要明白这些表达的差别。净土是畅佛本怀的教法，畅佛本怀怎么立根性？九界同归怎么立根性？凡圣同修，即是不立根性平等回施的事实。

多疑是我们的习惯，是学佛人的最大障碍，但又是最大动力。念佛可以用“疑”，只要敢于实践，你就可以破除疑虑。所以有疑就破除或觉悟它，这没问题。

净土教法畅佛本怀，平等救度，平等利益，平等回施，所以九界同归。同归怎么立根性？没法立根性！九界是哪一种根性？凡圣同修，九界同归，这都是不立根性，在佛的角度不判定我们根性，只是平等回施。

三辈九品是坚持自己业力的接受割裂、接受之异，没有随顺佛的愿力，没有随顺佛愿力。若随顺佛愿力则三辈九品不设。如出家、作诸功德、但信大乘教言——三辈九品是我们众生业力分的确认，是顺众生作为而设立，不是佛设，佛不设这些。

弟子：我随着师父讲的实践作愿，但有时会有粘着的东西？比如对乐受。

师：我们实践这个法可以运用七觉支分。你看看自己在哪个觉支分上方便。

弟子：乐受不想舍，苦受想舍。

师：不是这样的。假设你有乐觉支分的觉受了，你的乐觉支分一旦产生觉受了，你还在令它相续的时候，你有令它相继的概念，你就产生放逸了，就堕入世俗了，就称为染堕。觉支分就是不令它堕，它自然相续，*一个揭示一***个的。**我们在觉支分中会达成这样一个事实。

弟子：能不能教授七觉支的具体妙用？

师：时间所限，我们现在只能从业力角度相互撞击一下。可以下去查一查。可以设立七觉支分的课。他们专门倡印了七觉支分经，发过来后我们可以学习。

弟子：近门为什么是靠近的近？应该是进去的进吗？

师：这是翻译人的问题，过去在译经场上也会闹矛盾。昙鸾法师在《往生论注》上提到，《无量寿经优婆提舍愿生偈》要是他翻译就不这么翻译。像“宝性功德草，柔软左右旋”，他就不用草来表达佛的功德，他不这样设立了。另外这个近也有一种作意、推动、拉近的动态意识。他希望我们从凡夫心来进趣，这样一种动态的概念。他用这个概念使我们凡夫的心智与业力作为进趣到佛的国土。

弟子：礼拜门是仅限于礼拜这个动作，还是包括我所有触的感知？

师：在果地教言中，身业、口业、意业、智业、方便智业是对我们众生的身口意等作为，用我们最亲近的东西来作提示。若讲六根六尘六识等等会变得麻烦，而用最简单的身口意智方便智——你认为自己有智慧，就可以观察；你有方便，可以回向；意念发达，可以作愿；口业通利，可以赞佛；身心健康或者躁动多动症，可以拜佛。

所以这是直接借用我们比较亲近的三业，不再假设任何过多东西，比如学问知识等等。直接把你拉过来，让你去实践，我们人人都可以作为了。如果再讲多，又变成要学习很多知识才能作为了。现在这样讲，你的身口意直接就可以作为。

**实际我们的见闻觉知都可以礼拜。包括我们的依报都可以礼拜，舍依报而供养。**比如到一个有鲜花的地方，你说把鲜花供养佛菩萨，令佛欢喜；或者说愿见妙华庄严，愿生彼国，都没问题。可以举一反三，触类旁通，没有一个坚固实法。佛法的活泼是一个教法中有无量方便，都可以实施作为，有法的相应就可以。

弟子：我有很多问题一直没问，我想请师父帮忙分析，让我看清本质。

师：**所有问题严格说都是实相，是我们自己挖掘的宝藏，也都是障碍、迷失我们的业障。**说是我们觉悟的实相，是依本而说；说是我们自己挖掘的宝藏，是每一个问题你都觉悟其实质；说是我们的障碍，因为你迷失在一个问题上，它就像一堵墙一样挡着你，不让你走动。

昨天的复盘，意识到了这批上海股分歧一定会很激烈，因为情绪的错配，没想到比我想的还惨烈。我讲下原因。

1、周期的锚定

市场上太多人有着错误的锚定观，用高度来锚定周期是错误的，正确的做法是：

用指数的波动区间来锚定周期，用前高标的高度来锚定情绪。

下一句就是：

指数波动的强度锚定周期的强度

比如这里，有朋友昨天问我，上海股是不是17周期？这是很有代表性的问题，其实市场大多数人都是这么锚定的。这是错的。

上海股周期锚定的是1月23日开始的指数周期，所以这个周期内群体股票的强度和高度受指数高度制约。这是价格锚定。

那么17对这些票有影响么？有，当然有，他给了情绪锚定。

这就解释了，为何这个指数上升区间，那些票可以群体一字或者无量T字板，因为17的高度预期。

所以我昨天为何不看好今天接力？原因就是，情绪锚定的17在高位，价格锚定的指数却很不稳定。

于是今天指数下跌超预期，所以接力就这么惨烈，很简单的道理。

锚定准确了，自然就看清楚了。

这里要提到，周期论的情绪变化永远落后于价格变化，这是周期论的灵魂。市场一切的价格波动就基于此。

再进一步解释下：当情绪追上价格的时候，价格处于拐点区域；当价格遥遥领先情绪的时候，情绪一定会去追价格，价格因而继续上涨。

而这里的上海股就是，情绪锚定的17在高位，价格锚定的指数走弱，所以惨烈就是必然了。

我说的这些，基本上大多数人不会懂，价格和情绪这两个看似简单的东西，其实很难定义准确，而市场一切波动都围绕这两个词进行。

这里我在多说几句，一个模型：

a情绪追价格，你才有获利空间

b情绪追上价格，群体没空间，个体会穿越

c还有个特殊情况，价格倒追情绪，你会爆亏

（今天的上海就有点类似第三种情况，大家自己体会）

2、第二个原因就是大盘

昨天融券新规，直接导致量化策略需要进行大幅更改，所以早上这波杀跌是量化和机构合力的结果。机构我前面一直说，两点，一仓位重，二交易衰退：砸成长买高分红。

所以前面我一直讲，小票这里有很大的不稳定性，小票没多头，这个是最要命的。

3、投机这里，今天是退潮第一天，所以一是是老周期个别高标对抗指数继续艰难行进，高度未知，二是寻找对抗指数的情绪抱团品种，类似前面的17的属性，注意我说的是属性类似，不是高度对标。今天这个品种初露端倪，但是还需要等明天确认。

4、中特估（特别是高分红方向）

逻辑面：晚上又有消息递进了，中国神华的回复，某票的回购，还有国资委今天的会，来了句全面推开市值管理考核。这些在我昨天的文章里面都有预期。这算是逻辑的递进。

技术面：无异常，上午机构双向交易，砸成长买高分红，同时中特估成为避险资金的避风港，有些情绪追击资金进来，下午属于补跌大盘。明天可能有个震荡，然后再起来。昨天我说了一句：

这个板块慢比快好，低吸布局比等追高确认好

继续按这个策略来，布局好了，愿意做t就做t不愿意就拿着不动。

5、小票，成长股

最难搞的地方，没多头，你找不到小票做多的群体。

然后，机构每天早上睡醒，第一件事就是想怎么慢慢的减成长股。尾盘跌势放缓，是因为上面又指导了，卖的多的机构给拔了网线。

前面说了，量化今天基本上净卖，因为融券新规导致。所以后面大盘大概率成交会下去。

6、大盘

按目前的情况，这里最多是政策底，后面的市场底是必须的，现在的市场结构，各路资金情况我前面几篇文章都说了，大家可以回头翻翻看。

昨天情绪有些波动，写了篇初心，大家留言我都看了，我在互联网上留下那么多的文字和音频，是历史也是见证，人心是互相的，有些话很让我感同身受，我感谢大家的理解。

有些人，该把我拉黑就拉黑，别留情。

还有人说我不会打板，只会写那些没用的东西，呵呵，我打板的时候，你可能还在上小学。

今天文章前面抖了点硬货，总有人问我，周期论在哪在哪，说实话，我很懒，但现在还完全没整理完善。按我的性格，如果我拿出来，一定是至少我觉得非常满意的东西。但是呢，我想说一句，有人问我要周期论的时候，有的人已经整理成册并完全理解了周期论甚至可以用周期论稳定获利，因为我过去的文章基本上全部涵盖了，每次我都是实战+理论结合，事实上周期论实证之路早就开启了，而不是昨天。

前言

• 这篇文章是为 Stake Wars: Episode III - Challenge 5 所写的节点启动文档，记录了我的 Shardnet 节点启动步骤

• 节点启动环境：4-Core CPU / 8GB DDR4 / 500GB / Tencent Cloud / Ubuntu Server 20.04 LTS 64bit。节点费用大概 ￥360/月。

Challenge 1

账户创建

• 首先需要创建一个 Shardnet 的账户作为节点的控制账户。从 这里 进入账户创建页面，创建步骤与 Mainnet 账户一致。

Near-CLI 命令行工具下载

• 先更新下 apt

sudo apt update && sudo apt upgrade -y

• 安装 Node.js 与 npm 环境，已安装可以跳过

curl -sL https://deb.nodesource.com/setup_18.x | sudo -E bash -  
sudo apt install build-essential nodejs
PATH="$PATH"

• 然后可以检查下环境

node --version
npm -- version

• 安装命令行工具 near-cli

sudo npm install -g near-cli

• 检查下环境

near --version

Shardnet 环境

• Near 有四个网络，我们需要切换到正确的网络进行交互：

  • GuildNet

  • TestNet

  • MainNet

  • Shardnet

• near-cli 可以通过命令行与节点进行交互，但是首先需要设置正确的交互网络环境变量 NEAR_ENV

export NEAR_ENV=shardnet

• 上面的设置在每次进入新的终端后都需要重新设置网络，也可以直接把环境变量写进 bash 的配置中

echo 'export NEAR_ENV=shardnet' >> ~/.bashrc
echo 'export NEAR_ENV=shardnet' >> ~/.bash_profile
source $HOME/.bash_profile

• 最后可以检查下当前的网络设置

echo $NEAR_ENV

Challenge 2

节点环境

• Chunk Only Producer 节点的硬件要求如下，目前 Shardnet 存储占用为30GB左右，如果只是参加 StakingWar 的话可以暂时使用稍小的存储

• 首先可以检查下 CPU 是否支持

lscpu | grep -P '(?=.*avx )(?=.*sse4.2 )(?=.*cx16 )(?=.*popcnt )' > /dev/null \
  && echo "Supported" \
  || echo "Not supported"

• 安装下依赖环境

sudo apt install -y git binutils-dev libcurl4-openssl-dev zlib1g-dev libdw-dev libiberty-dev cmake gcc g++ python docker.io protobuf-compiler libssl-dev pkg-config clang llvm cargo

• 安装 python 和 pip 环境

sudo apt install python3-pip

• 安装 rust 的编译依赖环境

sudo apt install clang build-essential make

• 安装 rust 和 cargo, 出现如下图命令时，选择 1)Proceed with installation

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

• 执行这个命令让 cargo 环境生效

source $HOME/.cargo/env

节点客户端

• 在自定义目录下 clone 客户端代码

git clone https://github.com/near/nearcore
cd nearcore
git fetch

• 切换到指定 commit

• 编译客户端 neard

cargo build -p neard --release --features shardnet

• 编译完成后查看下版本信息

./target/release/neard --version

节点配置文件

• 节点的配置文件主要是这三个：

  • config.json : 里面可以对节点的运行，P2P，共识等功能进行配置

  • gensis.json：节点的创世状态配置，包括初始账户，合约，密钥等。这个配置文件也可以表示某个 snapshot 下的网络状态配置

  • node_key.json: 节点关联账户的公私钥信息

• 我们首先生成默认的配置文件

./target/release/neard --home ~/.near init --chain-id shardnet --download-genesis

• 然后需要修改 config.json 中的配置

  • boot_nodes：默认配置没有指定启动节点，这里需要指定一个

  • tracked_shards：默认配置没有指定验证的分片，这里可以指定为分片0

• 也可以执行下面的命令下载配置好的 config.json 进行替换

rm ~/.near/config.json
wget -O ~/.near/config.json https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/shardnet/config.json

启动节点

• 首先定位到 nearcore 目录，然后执行下面的命令, 看到下图输出说明已经启动成功，节点会先同步 全部head，然后再同步 block

./target/release/neard --home ~/.near run

• 节点启动正常之后，可以先 ctrl+c 停止节点，之后我们会用 service 来启动节点

添加验证者账户

• 现在需要给节点授权验证者账户用来进行质押，奖励等工作，首先输入下面命令

• 弹出的网页上进行账户的授权

• 网页授权完成后会转到无法加载的空页面，直接关闭就行，然后控台内输入刚才进行授权的账户名，等待返回成功结果 successfully

• 然后需要添加一个验证者账户的配置文件, 是你的节点id,格式是 xxx.factory.shardnet.near

• near generate-key <pool_id>

  • 拷贝生成的配置文件

  cp ~/.near-credentials/shardnet/YOUR_WALLET.json ~/.near/validator_key.json
  

  • 打开这个 validator_key.json 文件，将 private_key 改为 secret_key

  {
    "account_id": "xxx.factory.shardnet.near",
    "public_key": "ed25519:****",
    "secret_key": "ed25519:****"
  }
  

  使用 Service 启动节点

  • 打开 neard.service 文件进行 service 配置, 注意这里一般需要 sudo 权限

  sudo vi /etc/systemd/system/neard.service
  

  • 填入下面的配置，替换为系统的用户名，ExecStart 需要改为你的 neard 文件路径

  • [Unit] Description=NEARd Daemon Service [Service] Type=simple User=<USER> #Group=near WorkingDirectory=/home/<USER>/.near ExecStart=/home/<USER>/nearcore/target/release/neard run Restart=on-failure RestartSec=30 KillSignal=SIGINT TimeoutStopSec=45 KillMode=mixed [Install] WantedBy=multi-user.target

    • 这里可以新建一个 screen 窗口来单独运行 service

    screen -S neard_service
    

    • 在新弹出的控台窗口中启动 service

    sudo systemctl enable neard
    sudo systemctl start neard
    

    • 之后任何配置的修改都需要重载 service

    • ctrl + a + d 退出当前 screen

    • 想要重新回到 near_service screen, 执行命令

    screen -r neard_service
    

    challenge 3

    创建质押池

    • Near 是通过质押池与质押合约来保证进行质押交互的，质押池需要创建在账户上，同时账户也要配置到节点上。通过下面命令创建质押池

    near call factory.shardnet.near create_staking_pool '{"staking_pool_id": "<pool id>", "owner_id": "<accountId>", "stake_public_key": "<public key>", "reward_fee_fraction": {"numerator": 5, "denominator": 100}, "code_hash":"DD428g9eqLL8fWUxv8QSpVFzyHi1Qd16P8ephYCTmMSZ"}' --accountId="<accountId>" --amount=30 --gas=300000000000000
    

    • 这里的 填写质押池的名字，例如我的质押池这里就填写 jazzlost，最后质押池的完整名字是 jazzlost.factory.shardnet.near。 填写之前进行或授权的节点账户，我这里是 jazzlost.shardnet.near。 可以在之前的 validator_key.json 文件中找到。下面是我的节点创建命令, 创建成功可以看到返回 successfully created

      near call factory.shardnet.near create_staking_pool '{"staking_pool_id": "jazzlost", "owner_id": "jazzlost.shardnet.near", "stake_public_key": "ed25519:*****", "reward_fee_fraction": {"numerator": 5, "denominator": 100}, "code_hash":"DD428g9eqLL8fWUxv8QSpVFzyHi1Qd16P8ephYCTmMSZ"}' --accountId="jazzlost.shardnet.near" --amount=30 --gas=300000000000000
      

      

      • 节点的佣金可以通过下面的命令来调整

      near call <pool_name> update_reward_fee_fraction '{"reward_fee_fraction": {"numerator": 1, "denominator": 100}}' --accountId <account_id> --gas=300000000000000
      

      质押操作

      • 创建完质押池就可以进行质押了，只有质押量达到最低席位要求的节点才能被选中为出块节点, 填写完整质押池名称 xxx.factory.shardnet.near, 填写质押数量， 填写授权过给节点的账户

        near call <staking_pool_id> deposit_and_stake --amount <amount> --accountId <accountId> --gas=300000000000000
        

        • 如果需要解除质押，可以执行下面命令

        near call <staking_pool_id> unstake_all --accountId <accountId> --gas=300000000000000
        

        • 执行接触质押需要等待2-3个 epochs，然后就可以取出质押代币了

        near call <staking_pool_id> withdraw '{"amount": "<amount yoctoNEAR>"}' --accountId <accountId> --gas=300000000000000
        

        质押信息查询

        • 先 ping 一下节点更新节点信息, 填写完整质押池名字 xxx.factory.shardnet.near

        • near call <staking_pool_id> ping '{}' --accountId <accountId> --gas=300000000000000

          • 查询质押池总的余额

          near view <staking_pool_id> get_account_total_balance '{"account_id": "<accountId>"}'
          

          

          • 查询质押量

          near view <staking_pool_id> get_account_staked_balance '{"account_id": "<accountId>"}'
          

          

          Challenge 4

          Proposals 脚本

          • 节点需要在每个 epoch 内执行 ping 操作来申请下一轮出块的 proposal, 这里可以通过 crontab 脚本进行自动化

          • 首先创建一个 shell 脚本。 填写系统用户名， 填写质押池完整名称， 填写授权的账户

            #!/bin/sh
            # Ping call to renew Proposal added to crontab
            
            export NEAR_ENV=shardnet
            export LOGS=/home/<USER_ID>/logs
            export POOLID=<YOUR_POOL_ID>
            export ACCOUNTID=<YOUR_ACCOUNT_ID>
            
            echo "---" >> $LOGS/all.log
            date >> $LOGS/all.log
            near call $POOLID.factory.shardnet.near ping '{}' --accountId $ACCOUNTID.shardnet.near --gas=300000000000000 >> $LOGS/all.log
            near proposals | grep $POOLID >> $LOGS/all.log
            near validators current | grep $POOLID >> $LOGS/all.log
            near validators next | grep $POOLID >> $LOGS/all.log
            

            • 然后创建一下输出日志的保存目录, 同时添加读写权限

            mkdir $HOME/logs
            chmod +x $HOME/scripts/ping.sh
            

            • 然后创建一个 crontab

            crontab -e
            

            • 新打开的文件末尾添加触发任务, 保存退出

            0 */2 * * * sh /home/<USER_ID>/scripts/ping.sh
            

            • 然后启动 crond 任务

            service crond start
            

            • explorer 可以看到节点每两个小时自动执行 ping

            

            网络信息

            • 执行下面命令可以在控台打印P2P网络信息

            journalctl -n 100 -f -u neard | ccze -A
            

            

            • 日志中的 #1657223是当前的区块高度，后面是区块哈希，100 validators是当前网络验证者数量，30 peers 是节点的 peer数量，后面是一些网络信息

            • 执行下面命令可以查看本地节点版本信息

            curl -s http://127.0.0.1:3030/status | jq .version
            

            

            • 可以在 ShardNet Uptime Scoreboard 查看自己节点的在线时间，出块时间，节点排名等信息

            

1. 虚拟机的进化

1.1 虚拟机是什么

• 虚拟机是通过软件模拟、运行在一个沙箱环境中的完整计算系统。在区块链上，虚拟机就是智能合约的运行环境，是一个可以完全对外隔离的完整计算系统。区块链通过虚拟机来调用和执行智能合约，并要求所有节点都达成计算的确定性。

• 智能合约最大的特性就是要求任何环境下运行的确定性。由于运行节点的计算机或其它计算设备可能支持不同的CPU指令集，X86、ARM等；操作系统处理精度不同，32位，64位。不同机器对相同数据类型的表示也不一致，这样很难确保所有机器运行的结果一致。传统的 Java 虚拟机对于计算结果的少量的差异有一定的容忍度，但是在区块链上所有结果必须一致，因此一个新的、适用于区块链的虚拟机是必不可少的。

• 达到确定性的要求是不容易的，甚至为了代码的一致性还需要一套新的语言。区块链虚拟机还需要防止各类网络攻击以及恶意行为，所以还需要内置Gas之类的保护机制。也正是因为虚拟机的加入，区块链从1.0时代的分布式账本变为了2.0时代的分布式状态机，然后到了3.0时代的分布式状态集群。

1.2 理想区块链虚拟机特性

• 确定性：在调用同样的智能合约输入时，应该返回相同的输出结果，输出结果不依赖于时间、运行环境等外部的条件。包括运行时的资源消耗计算方式也需要准确。

• 安全性：沙盒执行环境，对于基本的网络攻击(日蚀攻击/女巫攻击/重放攻击/ DDOS )有预防机制。虚拟机发生故障不会影响其余模块。

• 灵活性：模块化架构，可以方便的组装到执行层中。多语言和开发框架支持。

1.3 技术发展

v1.0 - Bitcoin Scripts

• 比特币通过执行一组脚本来获取链上交易的状态与验证交易的有效性，可以看成区块链虚拟机的雏形。

• 比特币脚本功能上可以分为锁定脚本与解锁脚本，因为比特币没有帐户只有 UTXO 的概念，这两个脚本就是用来对 UTXO 有效性进行验证的程序。锁定脚本存在于每一比交易的输出中，里面明确了可以使用这笔输出的条件。解锁脚本则是用来生成特定解锁信息的。

• 整个交易会先执行解锁脚本，如果没有错误则复制主堆栈数据并执行锁定脚本，返回结果为TRUE则证明该解锁脚本满足锁定脚本的解锁条件，也就是满足这个 UTXO 的使用权。可以看到这里的脚本是整个交易过程进行扩展的对外接口。

• 比特币的脚本解释器是基于栈式结构的非图灵完备程序。操作和数据不分离，无额外存储需求。数据处理精度相对固定，空间使用松散。脚本能执行的操作简单，流程较为固定，灵活性和扩展能力差。

v2.0 - EVM

• 以太坊提出了智能合约的概念，并且提供了进行智能合约开发的高级语言以及图灵完备的虚拟机。用户通过交易与智能合约进行交互，虚拟机执行交易进行状态转换，所以以太坊更像是分布式状态机。

• EVM 本质上也是一个无寄存器，基于栈的解释器(interpreter), 通过解析智能合约编译出来的字节码进行数据操作。EVM 的栈帧宽度位256 bit, 一定程度上是为了符合密码学计算的要求(SHA256/Keccak256)，也可以减少 Opcode 操作降低 Gas 费用。EVM 对栈的访问不是严格的 FILO, 它允许一定规则的栈帧复制移动。每次操作只能取栈顶的若干元素，把结果压栈。当然也能够把栈顶元素放到 memory 或者 storage 区域保存

• EVM 具备了stack, memory, storage 三种存储模型。stack 和 memory 都是临时存储，合约运行时有效，运行结束后回收。 stack 最多可以容纳1024栈帧，memory 更像是堆，用来放数组，字符串和对象等复杂数据类型，storage是永久性储存，采用 uint256 的 kv 类型进行存储。

• EVM创造性的在虚拟机中内置了Gas系统，使得与EVM的交互花费成为可预估，可计算的。具体的资源消耗花费被定义在了Opcode中。Gas的设计在安全性与经济模型上都形成了开创性的作用。

v3.0 - Wasm & Others

• 随着智能合约的普及和发展，市场已经渐渐不满足于 EVM 和类 EVM 虚拟机，无论从性能还是安全性以及合规性来说，整个行业都知道 EVM 不会是最终解决方案，我们现在正处于市场对于新虚拟机解决方案的强烈需求中，这个阶段较为成熟的便是 Wasm 虚拟机，当然也包括 Move VM, Agoric VM, 3em, CKB VM 等小众虚拟机方案。

• 新的虚拟机方案大体都是对于 EVM 遗留问题的迭代，无论从开发或是用户层面，大家都在追求一种更近似于 web2 的体验，例如更好的运行时支持，更多的语言选择，更多的硬件架构适配，效率更高的指令集，更快的运行速度等。同时很多 EVM 的经典设计也得以继承，例如合约体系，Gas设计，账户模型，沙盒环境等。

1.4 问题与挑战

EVM 的遗留问题

• EVM 的架构是释放其原始性能的最大阻碍之一, 256位的栈帧虽然有利于哈希和椭圆曲线算法，但也使得 Opcode 到硬件指令的转换变得效率低下。这样的设计最初是以通用性与安全性为首要目标，间接的就是牺牲了性能，在处理大量复杂操作时速度是远低于 Wasm 虚拟机的。EVM 的 Opcode 规范一直没有更新，虽然开发过类似 evmjit 这样的JIT编译库，但也是实验性质的没有投入生产环境。虚拟机的优化是个费时间又费钱的工作，看下大厂在 JVM 或者 Wasm VM 上的投入就知道了。

• 智能合约的开发上也有很多遗留问题，类似标准库的缺失，调试和测试的不便等。其中最为诟病便是无法在原合约上进行升级，所以现在的项目为了达成合约升级的目的，一般会为同一个业务部署三份协议，一份核心合约直接和前端交互，里面会调用逻辑合约和数据合约来完成业务，之后升级时只需替换核心合约指向的逻辑合约地址就可以了，这样的弊端就是部署与维护开销变的更大了。其次 EVM 为了减轻计算密集操作(如密码学计算和哈希)的 Gas 开销， 提供了一些预编译合约，这些合约会在节点本地进行预编译，链上合约调用时再进行加载，如此一来进行任何新的预编译合约更新都需要全网硬分叉级别的升级了。对于这些问题，Wasm 等新兴合约有望解决链上合约的升级，调试测试与预编译的问题。

• 最后还要提一下浮点数的支持，EVM 中大部分人都觉得货币计算根本用不上浮点数，因为虚拟机的第一个特性就是确定性，而浮点计算的结果和平台与硬件架构相关。浮点数的缺失不会影响 Defi 的发展，但是很大程度会影响智能合约的适用领域，例如科学计算，机器学习，3D建模等。而新一代虚拟机例如 PlatOne-Wasm 就进行了浮点数改造，在一定条件下也可以保证计算的确定性。

模块化

• EVM 在设计之初可能没有想过之后会被如此多的其他链移植，以至于 EVM 兼容似乎成了行业标配。以太坊作为 Monolithic 链的代表在设计之初也没有预想过将 EVM 拆分为可以快速接入的模块化设施。所以在这股 EVM 兼容浪潮下，我们看到大部分公链都开始进行 EVM 的移植。早期 EVM 的移植集成并不是一件容易的事，首先更多的需要考虑底层链的特性从而对原始 EVM 进行修改适配，ABI接口实现，Opcode也会被修改。后来为了适配 ETH2.0 兼容 eWasm 的路线，以太坊也将 EVM 从客户端中单独剥离形成一个独立的模块，然后通过 EVMC ABI 接口与底层进行通讯来实现多虚拟机支持。越来越多语言的实现版本一定程度降低了 EVM 移植的难度，一定程度上加速了 EVM 的模块化。下面是一些 EVM 的实现版本，有包含在客户端实现中的，也有独立的：

  • Geth - Golang

  • Nethermind - C#

  • Erigon - Golang

  • OpenEthereum - Rust

  • Py-EVM - Python

  • evmone - C++

  • ethereumjs - Javascript

  • eEVM - C++

  • Hyperledger Burrow - Golang

• EVM 的模块化进程中大家也看到了多虚拟机支持的需求。兼容 EVM 是当下构建生态最佳选择，而兼容其他虚拟机是为了探索未来的合约发展方向。由于 App-Chain 发展的加速，应用的最小部署单位已经从合约变化到了应用链，对于应用链开发框架来说，虚拟机模块已经成了必须要考虑的部分。多虚拟机支持的架构以及内置的虚拟机模块可以给应用链开发者充分的选择权，可以预见模块化区块链的发展将会加速多虚拟机的支持以及 Wasm 之类的新虚拟机的普及，下面是一下支持多虚拟机的项目：

  • Cosmos - Evm / Wasm

  • Substrate- EVM/ Wasm

  • Solana - EVM / Pipeline (运行BPF字节码)

  • Avalanche - EVM / Wasm / Custom-VM

  • Near - EVM / Wasm

  • EOS - EVM / Wasm

  • Hyperledger - EVM / Wasm

2. Wasm

2.1 什么是 Wasm

• Wasm 是一种基于栈式虚拟机上运行的可移植编译目标格式。原始用途是作为可以部署在浏览器中的汇编对象，提升web应用的性能。和 EVM 一样 Wasm 只是字节码编码标准，可以实现多种虚拟机来运行。Wasm 标准由 W3C 制定，其开发团队分别来自Mozilla、Google、Microsoft、Apple，四大浏览器 Firefox、Chrome、Microsoft Edge、Safari 已经支持 Wasm MVP 版本的所有特性。

• Wasm 的出现很大程度上来源于 Javascript 的性能填坑史，JS 最初被设计为解释型语言，没有静态类型支持，所以在 JIT 出现之前基本只能运行时逐行解析与编译，最后才能作为机器码来执行，显然这里面有太多的重复工作。在网页应用进化的越发复杂，性能需求越发苛刻的情况下，JIT 氤氲而生，通过强大的上下文理解能力将一些大量重复调用的逻辑实时编译为机器码，将 JS 性能提升了20倍以上。可是 JIT 带来的性能很快也被榨干了，本质还是因为 JS 不是强类型语言。于是大家有了两个继续优化的思路，一个就是重新创造一门强类型语言作为 JS 的超集，然后编译成 JS，类似于 Typescript。另一种便是通过注释的方式在原 JS 代码上进行类型标注，然后用一个可以识别标注的 JS 引擎来执行，也就是 Wasm 的前身 asm.js，这种方式性能远远超过 JIT，直逼原生代码执行效率。再之后就是几个大厂将 asm.js 标准化的过程了，最后形成了今天的 Wasm。

2.2 Wasm 特性

• 安全

  • Host安全 - Wasm 在一个由虚拟机管理的沙盒中封闭运行，这使它无法看到主机，也无法直接与主机交互。对系统资源(文件、硬件或互联网连接)的访问只能通过该虚拟机提供的系统接口 WebAssembly System Interface(WASI) 进行，可以有效减少安全攻击面，在Web环境中 Wasm 严格遵守同源策略以及浏览器安全策略，这意味着某个页面上的恶意脚本没有办法通过 DOM 对象获取到另一个页面的数据，这些限制使得Wasm 模块很难做出不当行为。

  • 内存安全 - 与普通的编译程序相比，Wasm对内存的访问非常受限，对它们自己也是如此。Wasm 虚拟机不能直接访问尚未调用的函数或变量，不能跳转到任意地址，也不能将内存中的数据作为字节码指令执行。在浏览器内部，Wasm 模块只能获得一个线性内存(linear memory)进行操作。WebAssembly 可以直接读写该区域中的任意位置，或者请求增加其大小，但仅此而已。这个线性内存包含字节码、执行堆栈、当然还有运行 Wasm 虚拟机的区域分离。而且如果使用 Rust 这样的内存安全语言进行开发，在代码层面就已经杜绝了大多数内存问题。

• 性能

  • 包体文件小，加载速度快。

  • 与大多数现代硬件架构兼容的指令集，指令集效率高。

  • 大多数平台上趋于机器码的运行速度，一个可供参考的数据指标，JS 使用 JIT 后整体性能可以达到机器码 的1/20，Wasm 可以跑到机器码的 1/3 量级（视场景而定)。

  • Wasm 虚拟机的性能也需要辩证的看待，\这篇论文](https://arxiv.org/pdf/2012.01032.pdf))详细的比较了 EVM 与 Wasm 虚拟机的性能，结论是 Wasm 虚拟机引入的开销不低，并没有达到预期的性能。

• 开发

  • 多语言支持 - Rust / C++ / Javascript / AssemblyScript。前端会对特定语言进行词法分析、语法分析、语义分析，然后生成中间表达形式 IR(Intermediate Representation)。后端对 IR 进行优化，然后生成目标代码 Wasm。

  • 工具链支持

    • 主流JavaScript引擎 ( Chakra / V8 / Spidermonkey )

    • 非浏览器引擎 ( ml-proto / wasm-jit-prototype / wabt )

    • 更多的编译器与开发调试工具

2.3 智能合约为什么要用Wasm？

• 因为区块链需要扩容，为了最大程度的提高网络的交易吞吐量，智能合约的执行效率与安全性产生着非常大的影响，吞吐量直接影响了交易成本，间接影响了区块链的大量采用。合约开发语言与工具链也对开发者生态产生着影响。Wasm 就是一种可以继承 EVM 的特点(确定性，可终止性，独立性)，同时能够克服 EVM 暴露出的问题的一种解决方案。Wasm 内存安全、平台独立，可以有效地映射到所有类型的CPU架构, 指令集效率高，同时保有可移植性，Wasm 指令集可以很容易地通过移除浮点指令来达到 EVM 的确定性，这将使它适合于替换EVM语言。Wasm 在传统互联网领域的成功已经证明了其优势。在性能，安全，开发者生态上Wasm 是远远超过 EVM 的，也许以后会有更加适合智能合约的虚拟机，但是现阶段看来， Wasm 应该是不二选择了。

3. CosmWasm

3.1 基础模块

• CosmWasm 的原型来自 Team Gaians 在2019年柏林黑客松的项目，在黑客松取得成功后 Interchain Fundation 授予了 Confio 一笔 Grant 用于继续 CosmWasm 商业版本的开发

• CosmWasm 并非独立的区块链，而是作为 CosmosSDK 模块级别的开发工具链，和 CosmosSDK 中其它模块比如 Staking/Bank/Auth 等处于同一级别。任何使用 CosmosSDK 构建的项目都可以按需接入模块从来获得 Wasm 合约的执行环境。CosmWasm 还提供了一个拥有 Wasm 功能的 Hub模板，叫做 \wasmd](https://github.com/cosmwasm/wasmd)), 作为Cosmos Hub 集成 CosmWasm 的第一个实现版本。

• 这里有两张图可以清楚的看出 CosmWasm, CosmosSDK 和 Tendermint Core的层级关系。交易从 Tendermint Core 经过 ABCI 传进 Comos SDK 后，进行交易的解码后就会路由至相应的模块进行状态转换，最后再将执行结果通过 ABCI 返回给 Tendermint Core 进行 SMR(State Machine Replicated)操作。因为模块化的设计，结构清晰，流程可控性强。

3.2 模块特性

• 模块集成

  • CosmWasm 在设计层面上追求可插拔性集成，目标是释放多链虚拟机的最大可能性。所以在区块链架构或是语言上都尽可能的做最小化限制，只有很少的接口需要实现就可以完成集成，这对于新语言支持的添加是很便利的，不只可以使用 Rust，可以按需求添加 Golang 和 AssemblyScript 等可以编译为 Wasm 字节码的语言。

  • CosmWasm VM 的 runtime core 提供了 Rust 和 Golang 两种实现版本，对于其他非基于 Tendermint 共识构建的项目依然可以集成 CosmWasm 的虚拟机，享受 CosmWasm 在安全与性能上的优势。而只要是构建在 Tendermint 之上或是拥有 BFT 即时最终性(BFT Instant Finality)的区块链, 还可以享受到 CosmWasm 的 IBC 跨链支持。

• 合约安全

  • 合约的安全是 CosmWasm 最大的卖点，他们从 EVM 合约的漏洞中吸取经验，为一些最常发生漏洞的地方提供了原生的解决方案，其中包括重入攻击(Reentrancy)，类型溢出(Arithmetic Overflow)，默认可见性(Default Visibilities)，短地址攻击(Short Address Attack)，时间戳操纵(Block Timestamp Manipulation), 未初始化指针(Uninitialised Storage Pointers)等。这其中很多问题因为 CosmWasm 的架构设计天然就不存在了。

• Actor模型

  • Actor 模型是一种在并发与分布式计算中常用的设计模式，概括来说就是把 Actor 作为最基本的计算单元，Actor只拥有自己内部资源的访问权，通过 Dispatcher 来和其他 Actor 进行沟通，当受到消息后，Actor可以进行逻辑处理，创建Actor或者发送信息，然后决定收到下一个信息时的响应。 Actor 可以修改的只有自己内部的状态，每次只会处理一条信息，但是对于消息在 Actor 内部的处理是并发的。

  • CosmWasm 架构上通过运用 Actor 模型来增加合约执行环境的安全性，最直接的成果就是可以防止重入攻击(reentrancy attacks)。重入攻击本质上是利用了调用栈中的执行顺序，在状态改变执行前不断利用原始状态来进行攻击的。然而 Actor 间只能通过信息来沟通意味着处理下一次信息前调用栈一定是返回的状态，也就保证了栈中的状态更新一定是执行完成的，天然的就避免了重入攻击。

  • 虽然类似 EVM 的栈式合约调用会带来重入攻击之类的问题，但是优势就是跨合约调用的原子性，一次执行如果失败，所有栈上的状态修改都可以统一进行回退, 这个问题对于 Actor 模型来说就不适用。CosmWasm 则通过创建一个 SavePoint 来存储所有外部调前的全局状态，然后确保将调用分为多个子调用，如果某个子调用失败，则可以退回之前保存的全局状态，保证执行的原子性。

  • Actor 模型还有一个优势就是松耦合性，对于 Actor 来说，信息的发送和接受端都无关紧要。这对于模块化通讯来说意义非凡，合约可以和另一个合约进行通讯, ，也可以与 CosmosSDK 的其他模块进行通讯，对于 Actor 来说区别不大，只要是在 Dispatcher 中注册过的地址，都可以进行信息发送。

• 多链合约

  • CosmWasm 出现的本意就是作为多链生态的智能合约环境，同时也一直都将 IBC 集成作为高优先级任务。Actor 模型的异步调用方式和 IBC 也是非常契合的，在保证了本地链的执行有效情况下，链间通过 IBC 来确认各自链上执行的有效性， 最后才进行本地状态的变更。只要 IBC 能保证信息传送的有效性，跨链合约调用也就是安全的。

  • 目前 CosmWasm 和 IBC 的集成进度是合约已经可以通过 ICS20 在链间进行 CW20 代币的转移。下一步是 CW721 还有 Interchain Accounts 的集成。

• 合约升级

  • 之前我们讨论过 EVM 合约的升级问题，现在项目基本需要多个合约模块配合来支持升级功能，随之而来的代价便是更高的部署费用，更复杂的工程结构，引入更多的漏洞可能性。CosmWasm 从一开始就将合约的升级作为最高优先级，就像我们之前的判断一样，Wasm 一定可以优雅的解决合约迭代升级这种问题。

  • CosmWasm 将合约部署划分为三个步骤，一部分考量也是为了合约的更新。在初始化合约的步骤中，你可以选择设置一个拥有迁移权限的账户，之后下一次进行迭代升级时，首先上传代码，然后使用迁移权限账户发送一个迁移交易，这个交易会将合约指向新的代码并且完成链上数据的转移工作，最后进行初始化操作就完成了代码升级。整个流程自动化程度很高，项目也只需关心业务代码而无需考虑工程结构的拆分。

• 数据库存储

  • CosmWasm 的创作者 Ethan Frey 说过，以前他在传统互联网公司做后端工作，基本不会接触到用户存储的原始数据，而是使用 SQL 或者 ORM 库来对数据库存储对象进行操作。Solidity 中提供了很少的存储数据结构比如 mapping, 但是连遍历操作都没有原生支持，这个和 SQL 比起来就很简陋了。CosmosSDK 中提供了更多的存储数据操作，例如可以针对容器做遍历操作，但是依然是缺少像传统数据库的那种抽象层。于是CosmWasm 提供了 cosmwasm-storage 这个存储库，里面提供了类似 Singleton 和 Bucket 这种高级存储数据类型。CosmWasm 在之后还添加了加强版的存储库 cw-storage-plu，里面提供了 Item 和 Map 这样的数据类型。这些抽象存储类型的添加充分释放了开发的可能性提高了开发效率，也隔绝了对于原始数据的直接操作降低风险。Ethan 最后还说，用过了这些存储库之后，他再也不想回去用 CosmosSDK 进行开发了。

3.3 Contracts Pallet vs. CosmWasm

• Contracts Pallet 是 Substrate 提供的原生 Wasm 模块。两者最大的共同点是都属模块级别的执行环境，可以方便的进行集成。另一个共同点是依托于 XCM 和 IBC，两者的智能合约都能支持多链的合约调用。

• 两者最大的区别在于 CosmWasm 合约是基于 Actor 模型设计的，而 Contracts Pallet 合约是类似于 EVM 的同步执行模型。对于 Actor 模型的优势在上文已经进行了说明，Ink! 中为了处理这些情况提供大量的宏来帮助各种合约元素的生成。从代码角度来看因为 ink！因为很类似于 EVM 合约的开发思路，而且有大量宏的辅助，代码量相对 CosmWasm 会少很多，从这篇代码示例可以看到同一个功能合约，ink!用了 108 行，CosmWasm 用了 200 行。目前看来是因为 CosmWasm 缺乏程序性宏的使用，后期更新有望解决，我相信未来的合约生态一定是多种设计模式并存的。

• 有趣的是 polkadot 生态的 Wasm 平行链 Gear 也使用了 Actor 模型来创建智能合约。Gear 说通过 Actor 模型避免了共享内存带来的潜在风险，可以构建一个性能和鲁棒性更好的系统。合约间永远不会共享内部的状态，Actor 间获取或者修改状态信息都必须通过发送信息的方式。有趣的是传统 Actor 模型中不强调信息的时序性，而 CosmWasm 和 Gear 对针对时序性做了保证来满足智能合约的要求。

3.5 生态

• 参与了 CosmWasm 生态的项目现在应该是超过25个的，数量还在不断增多，这里简单介绍几个较热门项目。要理解 CosmWasm 生态的发展还需要回顾下 Cosmos Hub 的 Proposal 69，可以参考CosmWasm on Osmosis, Cosmoverse的跨链智能合约引擎

• InterWasm DAO

  • \InterWasm DAO](https://github.com/InterWasm/DAO)) 由 Confio / Terraform Labs / Enigma / Juno community representatives 发起，目的是帮助 CosmWasm 生态的发展。InterWasm DAO 拥有自己的代码库，给予生态项目 Grants / Bounties，加速生态的增长，组织生态内的活动。现在的组织成员还有 deus labs / Stargaze / envoy labs / Oraichain / DAO DAO。

• Juno Network

  • Juno Network 是由 Cosmos 生态中数十名开发人员、验证者和委托人推动的社区项目。作为 Cosmos 生态系统中的主权公共区块链，旨在为可互操作的智能合约运行提供环境。该网络最大的特点就是无许可和抗审查的合约部署。Juno 作为 InterWasm DAO 理事会成员，一直积极的在推进 CosmWasm 的发展，在开发者逃离 Terra 之后，Juno 有望吸引更多的 Wasm 项目加入。

• Osmosis

  • Osmosis 是 Cosmos 生态的多链 Dex 中枢，作风实验激进，是我最喜欢的项目之一。从出生第一天起就内置 IBC，常年霸榜 Map of zones - Cosmos network explorer，是 IBC 的最佳践行者。在传统 AMM 功能之外还不断的探索各种最新技术，比如无准入的 Frontier, 超流体质押(Superfluid), 以及即将到来的 CosmWasm 集成。虽然 Osmosis 上的 Wasm 合约部署是准入制的，但是借助于 Osmosis 的流动性以及强大的 IBC 中枢能力，我个人认为非常有可能出现生态创新级别的产品。

• Secret Network

  • Secret 是第一条具备隐私能力的 Wasm 合约链，通过 TEE(Truested Execution Environment) 来对合约的输入，输出以及状态进行加密，TEE 属于硬件级加密，比 ZK 系更成熟扩展性也更好，而且支持选择性披露信息，是有助于合规化的。Secret 形容自己是以太坊的可编程性 + Moreno 的默认隐私性 + Cosmos 的互操作性 。Secret 的前身是以太坊扩容项目 Enigma，是一家源于 MIT 的软甲公司，也是区块链行业最资深的一群开发者。隐私赛道无论现在还是未来都一直会是行业的热点，TEE + CosmWasm + IBC 想象空间是巨大的，可编程多链隐私计算也给 Cosmos 出现生态级创新产品打下了基础。

参考

详解 CosmWasm：兼具 Cosmos SDK 和 IBC 的跨链智能合约引擎 - Web3Caff

Introduction | CosmWasm Documentation

现代智能合约生态的比较 (jkyin.me)

NEAR | Robert Yan：基于 Rust 的智能合约开发框架的比较 | by BeWater Community | Medium

Why we believe in Wasm as the base layer of decentralized application development | Parity Technologies

The War on Virtual Machines: WASM vs. EVM | by kadeemclarke.eth | Momentum 6 | Medium

WebAssembly 101: Bringing Bytecode to the Web (fortinet.com)

以太机虚拟机 (EVM) | ethereum.org

区块链虚拟机技术简述 - 知乎 (zhihu.com)

从EVM到Wasm的范式转换，为什么波卡会成为公链的常青树？ (qq.com)

CosmWasm for CTOs I: The Architecture | by Ethan Frey | CosmWasm | Medium

ink! vs. CosmWasm | ink! documentation (substrate.io)

• 纵观整个区块链的技术发展，大部分技术难题以及解决方案都在围绕一个中心思想发展 - 怎么在不可能三角(性能，安全，去中心化)中找寻平衡，这里要讨论的模块化与数据可用性问题也不出其右。

TL;DR

• 模块化的出现不是偶然，而是必然。

• 数据可用性保证对轻节点与 Rollup 的安全性至关重要。

• 数据可用性扩容对于L1的吞吐量和费率都将产生巨大影响。

• 以太坊, Celestia 和 Polygon Avail等项目都在持续着数据有效性项目的研发。

2. 单体化(Monolithic)区块链

2.1 什么是单体化区块链

• 单体化架构的区块链可以理解为全节点需要同时处理网络内所有类型的工作，这里的工作类型我们抽象为三部分 - 执行(Execution), 共识(Consensus), 数据可用性(Data Availability)。单体化和模块化是相对概念，也是工程学发展的一种必然趋势。

2.2 单体化区块链工作流程

• 用户发送交易至节点

• 节点验证交易的有效性，执行交易，状态转换，如果有效则并放入内存池进行广播，否则抛弃交易回滚状态- 执行(Execution)

• 节点生成区块头，从内存池中选择一组交易，排序并放入区块，生成区块体，将区块存储到本地 - 共识(Consensus), 数据可用性(DA)

• 网络通过自己的共识机制挑选出块节点，出块节点广播自己的本地最新区块 - 共识(Consensus)

• 网络内其它节点收到区块后检查本地是否已经有了，没有的话需要重新验证交易的有效性与可用性, 并将此区块存储到本地 - 执行(Execution), 数据可用性(DA)

• 网络内节点达成最终性(Finality)后此区块成为链上最新区块

3. 模块化(Modular)区块链

3.1 为什么要解耦单体化区块链？

• 区块链作为执行状态机复制(SMR)的分布式网络，理论上就可以被分为数据，执行，共识等层级。单体化区块链遵循了 SMR 的设计，只是将所有层级的工作都放在了同一个节点(全节点)上执行。比特币，以太坊等项目都证实了其工程上的可行性。

• 回到不可能三角问题，扩容已经成了整个行业的圣杯。从比特币开始，区块链就不是科学上的创新，而是工程学上的创新。从单体化到模块化基本是工程学的发展规律，可以看一下现在的扩容技术，基本每一种都有很强的模块化趋势，或是走在模块化的道路上，看似模块化的出现是因为现前扩容的需求，实则模块化的出现是必然。

3.2 什么是模块化区块链？

• 模块化区块链是按照执行，共识/结算与数据可用性这样的模块粒度来进行解耦的区块链设计模式，每个层级由不同的网络进行维护，各层级充分发挥自身网络特性，最后通过可拔插的组合形成流水线的工作方式。

• 执行层突出强大和快速的计算处理能力，抛开共识和存储的束缚，可以通过非常少量的高性能节点来完成工作。

• 共识层需要保证交易的公正有效与安全，选出最符合网络共识要求的区块。共识层需要满足优秀的共识性与去中心化性。Polygon做过一个比喻，当你刷信用卡的时候，你的交易记录是先存放在信用卡中心的，信用卡中心会定期将一批信用卡交易记录发给银行，银行来确认交易的可用性并对账目进行记录更改。显然你不会因为信用卡中心的确认速度更快而把钱直接存到信用卡中心，因为银行才是金融体系内负责结算的角色，它有足够的信用背书，也有足够大的体量防止被攻击。

• 数据可用性层需要保证数据在保存前没有被二次篡改或者隐藏扣留，确保所有需要记录的交易信息都被正确的记录，数据可用性层的要求比较综合，需要共识性与不错的储存能力。在单体化区块链中没有数据有效性问题，因为数据被节点记录之前都会重新执行验证一遍，并且会和本地存储的区块进行比对来确保数据的有效。还是用上面的例子，银行收到信用卡中心的账单列表后，虽然已经确定了记账的方式，但是也会让多个结算员来对账单进行二次检查和结算，确保信用卡中心没有对用户的账单做手脚。DA 的概念是伴随着模块化区块链产生的，但是在 web 领域，基于 DA 的产品几乎每个人都用过的 - BitTorrent。

4. 数据可用性(Data Availability)

4.1 数据可用性的出现

• 数据可用性最初不是问题，L1中的数据是自然可用的。但是我们现在面临着扩容的剧变，数据可用性才成为一个不可避免的话题。只有保证所有交易数据的可访问和可下载，L1或者轻节点才能对Rollup 上的状态进行跟踪和重构。

4.2 DA是必不可少？

轻节点验证数据可用性困境

• 比特币在设计时就提出了 SPV(Simple Payment Verification) 的概念，即使不运行网络的全节点也可以使用网络的方式。这类节点称为轻节点，它们只下载区块头，不下载具体的交易数据，不会去验证交易的可用性，只保证同步的是最新的区块头，也就是只能确保区块是有效的，对于区块内交易的可用性则是完全信任全节点的。

• 因为交易数据是记录为 Merkle Tree 的结构，轻节点虽然拥有验证某条交易的可用性的能力，但是对于全节点恶意隐藏或是扣留的交易数据，轻节点由于只有区块头，是很难确认具体哪条交易信息是无效的，除非下载全部交易数据，总结就是确认交易无效容易，确认交易是否存在是困难的。

• 传统分片(Sharding)扩容方式中，矿工会被分配到不同的分片上处理该分片的工作。矿工需要运行该分片的全节点加上其它分片的轻节点来保证跨分片操作的能力。因为分片安全的分割性，如果某个分片的节点作恶，很容易出现上面描述的轻节点验证数据可用性困境，大大降低分片的性能与安全性。

Rollup强依赖数据可用性保证

• Optimistic Rollup

  • 在 Optimistic Rollup 扩容方式中，运用一种称为 Sequencer 的高性能服务器对交易进行验证与执行，最终将交易批量打包(batch)传回L1进行储存。Sequencer 是更加中心化的节点，处理速度非常快，L1的共识层是无法跟上这样的处理速度进行共识的，所以为了防止 Sequencer 的作恶，我们先假设 Sequencer 处理的工作是有效的，然后还有一类角色负责定期从L1读取 Sequencer 提交的交易来验证区块的有效性，如果发现有无效交易则可以提交欺诈证明(Fraud Proof)来进行可用性挑战，如果数据最后被认定无效，则 Sequencer上的状态也会回滚至有效前。

  • 这里的问题是，如果要验证Sequencer提交的交易的可用性，需要先保证Sequencer提交了所有它验证过的交易，没有隐藏或是扣留等，也就是需要保证数据的可用性，否则是无法进行欺诈证明验证的。Optimistic 和 Arbitrum 等 Rollup现在的解决方法是将所有交易发回以太坊，以太坊来进行数据可用性工作

• ZK Rollup

  • 对于 ZK Rollup(Zk-SNARK/Zk-STARK)的 Sequencer 来说，不存在欺诈性证明问题，在提交 batch 交易时还需要同时提交零知识可用性证明，只要证明是有效的，则交易一定是有效的。即便如此也还是需要将交易数据发送回L1进行记录，为了防止有一天此 Rollup 服务终止后，用户依然可以用L1上保存的数据恢复账户状态，避免资金在 Rollup 中的锁死。这个时候如果没有数据可用性保证，也就无法恢复正确的链上状态。这个也被称为 Rollup 链上状态持久性问题。

4.3 DA扩容问题

吞吐量

• 受限于底层区块大小限制，区块大小其实是共识层和数据可用性层共同的问题。以太坊为例，区块大小的均值在 50-60kb，区块大小限制了单位区块可以包含的交易数量。Rollup 现在是将批量交易(batch)信息通过 calldata 字段进行压缩保存，其效率必然受限于单个区块可容纳交易限制。

• 受限于底层数据可用性验证效率限制，现在的 Rollup 例如 Optimism，数据可用性依然依赖 L1(以太坊)来进行，和单体化时期并没有区别，全节点下载所有交易，通过L1上的智能合约计算 Merkle Tree 等方式来验证区块内所有交易的可用性，然后进行本地保存，网络中所有节点都需要重复这个步骤。以太坊的TPS在14左右，数据可用性验证也差不多是这个速率，可见数据可用性验证的效率对 Rollup 效率影响之大。

存储成本

• 受限于底层存储成本限制，因为存储的高昂费用，使得用户最敏感的交易费用在L2上并没有得到大幅度的减少。现在 Rollup 的费率主要由固定成本与可变成本两部分组成。其中对于Rollup费率影响最大的便是 calldata 的存储费率16gas / byte。

  • 固定成本：L1 Base Tx Fee 21000 + 状态写入成本 20000

  • 动态成本：L2 Base Fee(可忽略不计) + calldata 写入成本(16gas / byte)

• 数据可用性的存储和通用的存储是有区别的。数据可用性存储不会对大文件存储做优化，反而需要对数据验证做更多优化。可以看这篇了解更多。

4.4 DA扩容技术

二维R-S纠删码(2D Reed-Solomon Erasure Coding)

• 纠删码是在原始数据上附加一些额外的数据，保证原始数据在一定的兀余度内的丢失都是可以通过算法恢复的，几乎所有分布式数据网络中为了保证数据的冗余性都会使用纠删码进行数据可用性保护，CD-ROM 上也大量使用纠删码来保证一定程度的物理损坏不会导致数据遗失。

• 二维R-S纠删码是一种数据编码方式，解决的问题是通过增加数据兀余度与采用特别的数据排列方式，帮助节点无需下载所有交易的情况下就可以快速验证数据的可用性。全节点将数据附加纠删码后，再被切分为横纵轴数量一样的带有奇偶校验数据的数据分片，现在数据呈二维平面排列，然后计算出行和列的 Merkle Root，同时也需要用行和列的 Merkle Root 计算一个整体数据的 Merkle Root， 放入区块头信息中供之后快速校验。

• 可以看出一个全节点如果想隐藏一笔交易，那几乎就不可能了，因为任何的修改都会导致二维数据矩阵实质性的变化，非常容易被检测出来。网络内全节点如果检测到任何数据有效性问题，也会通过数据有效性欺诈证明来快速通知轻节点。

数据可用性采样(Data Availability Sampling)

• 数据可用性采样 + 二维R-S纠删码几乎是数据可用性项目的通用设计了，也是几个项目技术细节上有差异化的地方。以太坊的Dank Sharding也不断在进行数据可用性采样方面的研究。

• 在交易数据完成二维R-S纠删码编码，区块头也广播之后。轻节点就可以通过区块头中的行与列的 Merkle Root 计算出整体数据的 Merkle Root 并与区块头中的数据进行对比。如果整体数据的 Merkle Root 没有问题的话，轻节点再进行一个非常小的数据采样测试。例如随机选择第3行与第5列，之后就是与 SPV 中轻节点验证交易可用性方式一样了，要求全节点返回计算需要用到的节点路径进行哈希计算。最后再与全节点给出的第3列与第5行的 Merkle State 数据做对比就完成了一次采样验证。

• 这个方案最重要也是最美妙的一点在于，验证数据量与计算量很小，支持大量轻节点的加入，并且节点数量越多，区块的可用性概率也越高整个网络也越安全，对于检测数据隐藏或者扣留的情况非常高效。

命名空间默克尔树(Namespaced Merkle Tree)

• 这个是 Celestia 首先提出的技术，简单说就是将整个默克尔状态树划分了归属，全节点做验证时只需要下载自己归属下的那部分树结构就可以了。这样的好处是可以同时支持不同的执行层数据的可用性验证。这个设计充分体现了 Celestia 的模块化主义与多 Rollup并存的展望。技术细节可以参考这篇文章。

KZG承诺(Kate-Zaverucha-Goldberg Commitment)

• 使用 KZG 作为数据可用性的状态根最初来自于以太坊的 Danksharding 方案。KZG承诺的作用和 Merkle Root 一样，是对于整体状态的一种证明方式(proof of inclusion)，可以看做另一种 Merkle Root，只不过它哈希的不是数据，而是多项式。数据量更小，可用性证明更加高效，而且所有叶子节点都在同一个 polynomial(多项式)上，通过增加叶子节点就可以进行纠删码编码(Erasure Coding友好)。

5. Danksharding

5.1 Proto-Danksharding(EIP-4844)

• Proto-Danksharding 是 Danksharding 的一个早期先行版本。在交易信息中包含了一个额外的存储空间字段 - blob。每个blob有 128kb 空间，每个交易最多有两个blob，每个区块最多包含16个blob，blob不可以被EVM执行。blob都使用 KZG 承诺进行多项式哈希，用于之后的数据可用性验证。之前 Rollup 的批处理 batch 数据都是通过 calldate 字段传入L1，现在可以直接放到blob中。

• 这里最重要的是，blob不是永久存储的，可以理解为有时效性的缓存，每隔一段时间(30天)以太坊上的blob数据是会被清除的，通过这种缓存的方式来减轻以太坊的存储压力以及减少存储费率。因为30天后blob数据会被清理，所以需要自行存储这些历史交易数据。以太坊共识层的目的不是保证永远保存所有历史数据。相反，其目的是提供一个高度安全的实时公告板，将历史数据存储的工作交给其它更适合的网络来进行，以太坊也在全力转向模块化趋势。

5.2 Danksharding

• Danksharding 是以太坊的新分片设计提案，围绕 Rollup-Centric 的以太坊发展路线，提出了很多数据可用性层相关的改进。此分片方案给 rollup 的批处理batch数据提供大量的存储空间 blob。以太坊协议本身并不试图解译这些blob，验证一个 blob 只需要检查该 blob 是否可用——即它能否从网络上下载。这些 blob 的数据空间预期是为支持高吞吐量交易的二层 rollup 协议所用的。

• Danksharding 将 Proto-Danksharding 中blob数量提升了16倍，最大交易大小从2M上升到32M, 目标交易大小从1M提升到16M。blobs 分散存储在 Becon Chain 上，单独作为数据可用性层工作。依然是运用纠删码技术，每个节点只保存blob的数据片段，整个网络来保证blob的数据的完整性(和 BitTorrent 一样)。blob使用数据可用性采样(DAS)的方式配合 KZG 状态根来验证数据可用性，提交提交 attestation，attestation 达到阈值则认为block有效。再配合 EIP-4488 来减少 calldata 的存储费用，包括提供独立的数据有效性分片来存储blob，可以说是在数据可用性扩容上全力导向 Rollup-Centric 发展路线了。

6. Celestia

• Celestia 是近期最重要的模块化区块链项目，也是推进数据可用性与模块化区块链落地的先驱。构建于 CosmosSDK 之上，专注于提供数据可用性服务，不执行任何交易。他们率先提出了让轻节点使用二维R-S纠删码进行数据可用性验证，同时开发了命名空间默克尔树来支持多种 Rollup，也提出了量子引力桥(Quantum Gravity Bridge)使用 Celestia 作为以太坊数据可用性层的扩容方案。

• CEO Mustafa Al-Bassam是 Chainspace 的 Co-Funder，这个项目后来被 Facebook 收购。首席研究员 John Adler 来自 ConsenSys,曾经帮助 Optimism 完成了第一版技术规范。

• 我觉得模块化在社区的兴起大部分是因为Celestia描述了一种全新的模块化区块链技术栈，其中以Rollup + Cevmos + Celestia的组合受到最多关注。Cevmos是Celestia与Evmos团队合作推出的模块化结算层，使用Optimint(Optimistic Tendermint)共识, 基本是完全为EVM Rollup优化的，还结合了Cosmos网络的互操作性，组合性等优势，十分值得期待。

7. Polygon Avail

• 谈到L2怎么能少了号称layer2聚合器的Polygon。Avail是Celestia的竞品，作为polygon的layer2聚合器版图的一部份，构建于Substrate之上，专注于数据可用性层的服务。在我看Avail也是最有可能在Polkadot生态出现原生的数据有效层项目前的DA选择方案之一。Celestia已经为Cosmos生态描绘出一种极高灵活度与扩展性的架构，我相信Substrate生态也会不甘落后的。

• Avail 的思路与 Celestia 基本相同，区别主要在于纠删码的生成以及采样验证环节。Avail 在二维R-S纠删码编码阶段大量使用KZG承诺。Avail将数据展开为n * m的矩阵，对每一行都构造一个多项式，然后为每一个多项式都生成一个 KZG 承诺放入区块头。之后轻节点便只需要原始数据和 KZG 承诺便可完成可用性验证。

8. Startwar Validium & ZkSync ZkPorter

• Validium 和 ZkPorter 是 Zk-Rollup 两大巨头 Startware 与 ZkSync 推出的自家链下存储服务。本质是是为了解决上述L1的瓶颈舒服Rollup快速大规模应用的问题，通过将交易数据存储在为Zk交易数据优化过的相对中心化的网络中而不是以太坊来大幅降低交易费用。我觉得这是对于以太坊过于缓慢开发进度的一种折衷方案。毕竟安全性是有代价的，不过这样服务的出现肯定也能打中一批目标用户。

9. 参考

Celestia 101 - 模块化区块链 — Yicheng (mirror.xyz)

研究｜Celestia会成为DA模块的头牌吗？ (qq.com)

Why Do We Need Modular Blockchains For Scalability? | by Yong kang Chia | Apr, 2022 | Medium

WTF is Data Availability?. and why solving the “data availability… | by Yuan Han Li | Blockchain Capital Blog | Medium

A Non-Technical Introduction to Rollups – Mechanism Capital

What Is Data Availability? | Alexandria (coinmarketcap.com)

How the Data Availability Layer can Shape the Future of Blockchain | by Huobi Research | Huobi Research | May, 2022 | Medium

Celestia MVP 发布：数据可用性采样轻客户端 — W3.Hitchhiker (mirror.xyz)

Vitalik: Proto-Danksharding FAQ | 登链社区 | 区块链技术社区 (learnblockchain.cn)

基础数据结构 :: 以太坊技术与实现 (learnblockchain.cn)

https://forum.aurora.dev/t/proposal-an-introduction-article-of-aurora-by-chinese/600

前言

• Near主网上线将近2年了, NightShade动态分片也已经进行到了Phase1, 最近Aurora推出了Aurora Plus服务，作为Aurora的忠实用户，借这个契机想来梳理下Aurora的产品线。

1. Aurora Engine

1.1 什么是Aurora Engine

• Aurora Engine是Near上用Rust写的一组智能合约，是Near上支持EVM开发的解决方案与工具集

• Aurora Engine核心基于SputnikVM(来自Parity的Rust EVM实现)，可以无缝部署Solidity合约。完全支持MetaMask/Remix/Truffle/HardHat/OpenZepplin等现有EVM开发工具。

• Aurora享受Near的一切技术优势，随着Near的动态分片逐步上线，Aurora也将成为第一个真正意义上支持分片的EVM。这是非常值得期待的，Aurora + Near被很多人看做ETH2.0的先行网。

• Aurora不是Moonbeam/Evmos/Polygon这样链级别的EVM层，而是更像合约级别的Layer2。拥有自己的RPC服务，Execution在Aurora节点上执行，Settlement和DA放在Near上，所以安全级别等同于Near的安全级别。Gas Fee使用$ETH结算，非常方便部署在以太坊上合约的迁移。

• 总结起来就是，对于以太坊，Aurora就是侧链。对于Near，Aurora就是Layer2。作为Rust智能合约实现的EVM运行环境，无需维护自己的共识与节点。这样的协议我暂时只见过Aurora。

• 这里吐槽下，我没有找到Aurora的白皮书。可能Alex是不喜欢写字，只喜欢撸代码那种吧。。。

1.2 架构

• Execution Interface

  • 底层与Near Core Api交互

  • 上层提供与EVM交互的RPC服务(Deploy Contract/Call Method/View Method)

• Token Interface

  • 底层与Rainbow Bridge交互

  • 上层提供符合FT Standard(NIP-141/NIP-145/NIP-148)的各种资产的跨链与操作

1.3 流程

• 用户发送签名的ETH交易至RPC代理服务(下文会提到的Aurora Plus服务)

• RPC节点包裹ETH交易到Near交易中，并发送Near交易到Near节点

• Near节点解开包裹信息，计算交易费并将Eth交易信息作为参数调用Aurora的合约接口

• Aurora Engine执行Eth交易并计算实际使用Gas，支付Gas Fee给RPC代理

1.4 优势

• 扩展性

  • Aurora Engine底层扩展依赖于Near的动态分片技术的扩展能力，本质上Aurora的扩展能力等同于Near的扩展能力。

• 费率

  • 从流程中可以看出交易底层的Gas其实是用$NEAR支付的，依赖于Near的低费率，最终交易费率也比以太坊一层便宜500倍，这还只是在未开放分片的情况下，分片逐步开放后费率只会更低

  • Auroa Engine也在不断优化，使用更少的GasFee($NEAR),支持执行更多的EVM工作，这个也是最近几个版本更新的重点

• 互操作性

  • 因为Aurora Engine本质是Near上的一组智能合约，和Near上其它合约交互也就是合约级别的交互了，非常方便和安全。

• 最近Near上的原生DEX - Ref Finance上线了Liquidity Aggregation功能。Ref直接可以使用Aurora和Near生态内的流动性，进行最优价格路径的组合，进行交易。最厉害的地方在于所有操作都在Ref的面板上就可以完成。这个是Aurora互操作性最好的体现。

• Liquidity Aggregation原理是通过Aurora提供的SDK进行Aurora内部生态数据的检索寻找最优价格。然后通过Aurora的cross-network contract call就可以仅使用Near账户在Aurora内进行Swap操作，最后再通过Rainbow Bridge将资产跨回Near。Cosmos近期开放的Interchain Account功能，其实在Near和Aurora上已经有了成品，而且安全性也是高了一个等级的！

1.5 数据

• Aurora的账户数量已经突破900k, 从今年4月起有较快增速。对比Avalanche C-Chain的3000k和Arbitrum的600k, 增速不错，短期还有较大增速空间。

• Aurora的TVL在5月达到峰值1.4b，后续因为大盘回落趋势下降到411m。TVL和独立地址增速有较强关联性。和Arbitrum的2.6b峰值以及Avalanche的13b峰值还有较大差距。

2. Rainbow Bridge

2.1 什么是Rainbow Bridge

• Rainbow Bridge是去中心化的轻节点类型跨链协议，和Aurora Engine共同组成Aurora Runtime

• 目前支持ETH/Near/Aurora之间的代币跨链，会逐步开放其它链

• 不限于通证转账，未来会支持通用型信息跨链来实现跨链互操作

2.2 架构

• 轻节点(Light Clients)

  • ETHOnNear Client

    • 用Rust实现的一组合约，用于在Near上记录以太坊的区块头信息

    • 使用Prover检验Near端有效性(Event/State/TX)，预先计算DAG文件，保存默克尔树根

  • NearOnEth Client

    • 用Solidity实现的一组合约，用于在以太坊上记录Near的区块头信息

    • 使用Prover检验ETH端有效性(Execution/State/TX)

    • 因为以太坊对于Near所使用的Ed25519签名支持的缺失，所以NearOnEth轻节点的签名验证使用乐观证明模式(Optimistic), 通过WatchDog来进行有效性挑战

• 中继(Relays)

  • Relay是运行在服务器上的一组脚本，负责读取链上的区块信息并发送区块头给轻节点记录上链

  • Eth2Near Relay

    • 发送ETH区块头给EthOnNear Client，每个新的ETH区块都发送

  • Near2Eth Relay

    • 发送Near区块头发给NearOnEth Client，每四小时发送一次(挑战期)

  • WatchDog

    • 监控提交的Near区块头签名有效性。因为以太坊对于Near所使用的Ed25519签名支持的缺失，无法验证签名，NearOnEth Client变成了Optimistic客户端，所以需要挑战

    • EIP665上线后以太坊会提供Ed25519签名的precompile, 之后就可以取消WatchDog和4小时的挑战期

• Connectors

  • 跨链两端的一组智能合约，定义跨链时两端资产具体遵循的标准(ERC-20/NEP-141等)与操作(Lock/Transfer/Mint/Burn等)。对于以太坊现在有ETH Connector/ERC-20 Connector/Near Connector。

  • 未来可以创建新的Connector作为Rainbow Bridge前端插件来进行资产和数据的跨链(NTF Connector/DAO Connector)

2.3 流程

1. 用户在源链发送签名交易到Rainbow Bridge前端

2. Rainbow Bridge前端与Connector交互，进行资产的Lock等操作

3. 基于这次的交易信息，前端生成一个Proof证明源链上发生了交易

4. 等待Relay将区块信息同步到目标链的轻节点上

5. 提供之前生成的Proof给目标链的对应Connector

6. 目标链Connector检查目标链的轻节点区块，并自行生成一个Proof

7. 比对两次生成的Proof是否一致，目标链Connector进行资产的Mint等操作

8. 完成跨链

3. Aurora Plus

3.1 什么是Aurora Plus

• Aurora Plus是服务于Aurora用户的一系列会员制服务。现在的主力业务是Aurora Lab提供的中心化RPC服务，与大家熟悉的Infura/Alchemy是同类产品, 目标是大规模商用市场。还有一系列Staking/Governence/KYC等服务于整个生态和用户的功能，下文会说明。

3.2 什么是RPC服务

• RPC是远程过程调用框架(Remote Procedure Call Protocol)，不是协议。RPC在分布式系统中提供了类似于调用本地方法一样调用接口的功能，简化了分布式系统相互调用服务时的复杂度与耦合度。

• 其它RPC服务商也有提供Aurora的RPC服务，当然你也可以运行自己的Aurora RPC服务。

• Aurora Plus提供的RPC服务和大多数RPC服务一样，个人用户有免费RPC使用限制，当然也有专业用户计划

3.3 其它服务

• Staking

  • Aurora Plus另一个重要的会员服务就是Staking与Airdrop聚合服务。通过质押$AURORA来获得治理权，同时通过国库的提案与生态内多个项目合作，获得项目代币Airdrop

  • $AURORA的staking是auto-compound的，Claim收益时会有一个冷静期，同时根据质押时间也会有一个Booster倍数激励

  • Booster意在激励早期支持者，同时分散化代币持有以及限制鲸鱼用户(大多数私募还在lock阶段)。现在$AURORA的Stake有4倍的奖励倍数，之后奖励倍数会线性递减到2027年，每次新的Stake的Boost倍数都会被单独计算，之前Stake的Boost倍数不受影响。每次Unstake任意数量$AURORA都会导致还在Staked的$AURORA被重新计算Boost倍数。auto-compound的部分没有Booster。

  • 生态内现在合作的项目已经有：

    • Bastion

    • Aurigami

    • USN

    • Trisolar

• Governance

  • 将来会实现基于质押时间权重的投票权

  • 国库的所有行为也会通过提案来治理，其中会有200million的$Aurora用来激励整个生态，其它的国库Grant，平台变动，项目启动等也会进行治理

• Private Transaction

  • Aurora Plus与Near合作对交易的MEV攻击提出了很好的解决方案，可以更好的保证交易的隐私性从而避免机器人抢跑和三明治攻击等

• KYC/DID

  • Aurora Plus还将提供KYC服务，KYC记录在Near上。同时还会提供通过TouchID/FaceID等物理验证方式作为DID(Decentrilize Identity)授权方式(之前只有Dfinity实现了这种TEE的DID授权方式)

  • Near生态内现在还没有出现做KYC的项目，现在看来作为Near流量入口的Aurora Plus其实是最适合来做这个事的。Aurora Lab作为实体企业也会为KYC的可信度做背书。

• Bussiness Account

  • Aurora Plus提供了Business Account，项目方可以使用这类账户来管理大量子账户，代替用户创建管理以及支付使用费用。虽然看起来非常不web3，但是不能否认对于大规模商用这种模式的必要性。

  • 官方给出的一个用例一个游戏开发商可以在底层集成这种账户模式，对于游戏玩家来说，操作上是完全无感的，和之前不会有太多区别。这个服务也体现了Near生态一直以来的产品目标 - 让web2用户无感的过渡到web3世界。

4. Aurora对于Near的意义

• Aurora之于Near就像，C-Chain之于Avalanche，Moonbeam之于Polkadot，Evmos之于Cosmos。是非EVM原生支持的区块链最重要的组件，也是整个链生态起始的地方。

• Co-Funder Alex也是Near团队的创始人之一，非常了解Near，和Near团队非常紧密的合作和推进新功能的上线，对于Near来说提供了最好的试验田，我记得之前的Staking Farm功能就是Aurora第一时间集成上线的，所以说Aurora是Near的第一方团队应该没人意见。

• Aurora也是Near的TVL担当，近期一系列活动吸引了大量的资金把Near重新推回到了公链舞台的聚光灯下。Aurora生态发展非常迅猛，几乎所有品类的产品都在持续上线，配合Aurora Plus的助力，非常有希望把Near再次带到web2用户领域。

• Aurora和Octopus Network以及Near Core Team被称为Near开发铁三角，现在看来确实缺一不可，Aurora在前期为Near赚足了眼球和TVL，Octopus为未来的应用链普及打下了基础，Near团队则在底层不断推进夜影协议的上线，三方都在为未来的大规模商用齐心协力！

5. 参考

Aurora Engine | Aurora Documentation

Aurora Continues to Push EVM Scaling With Engine 2.4.0 Release | NEAR Protocol (medium.com)

Aurora launches on NEAR Protocol

How the Rainbow Bridge works - Aurora Blog

Introducing Multi-chain Liquidity Aggregation | by Ref Finance | Apr, 2022 | Medium

基础概念

1.什么是Arweave？

• Arweave是去中心化数据存储的协议/网络

• Arweave实现了数据的永久储存

• Arweave实现了一次付费永久储存的经济模式

• Arweave不是传统意义的链式结构，而是使用了类似图状的Weave数据结构，新节点无需同步所有旧数据

• Arweave使用SPoRA(（Succinct Proofs of Random Access，随机访问的简洁证明）)共识，该共识鼓励存储更多的数据，储存更少节点储存的数据。通过储存内容 + 算力的方式来竞争出块，更多共识细节可以参考这里

2. 什么是中间件？

• 中间件是一类介于系统层与应用层中，掩盖系统层开发细节，直接提供应用层业务所需功能的工具

• 区块链领域的中间件可以理解为，避免了直接与底层链端交互开发，辅助上层应用进行开发的一系列工具，例如Chainlink/The Graph/Infura等都属于中间件

3. 什么是KYVE?

• KYVE是一组提供数据流标准化存储与验证的去中心化协议

• KYVE协议构建在一条基于CosmosSDK的公链Korellia上

• KYVE是Arweave生态最重要的应用之一，作为存储中间件双雄KYVE + Bundlr之一

4. KYVE解决了Arweave什么问题？

4.1 扩容问题

• 链上储存扩容

  • 传统区块链类似Ethereum全节点大小已经达到700G, 日益增长的链数据会造成节点的储存压力,也就是我们常说的状态爆炸问题，不断提高着新节点加入的门槛。KYVE最主要的一项业务便是归档其它区块链的数据并储存至Arweave。区块链数据在归档到Arweave后可以压缩裁剪掉可以通过计算还原的历史中间状态数据，仅保留较近一段时间的中间状态数据和最新状态数据用作节点验证，大幅缩小储存压力。

  • KYVE使用了一种被称为Bundle的批处理技术，将多个数据进行捆绑处理，大大加快存储与验证的效率, 也降低了存储开销。某种程度上KYVE也可以看作Arweave的Rollup。

  • KYVE使用不同的Runtime模块来匹配不同类型的区块链数据类型，抓取区块数据存储后，也可以非常方便查找，提供了一定程度的检索功能了

• 链下计算扩容

  • 传统区块链例如Ethereum的节点需要同时负责执行/结算/共识/DA的工作。执行的意思就是每次智能合约的调用，几乎所有节点都需要去执行一遍计算。这样做安全性非常高但是也有显而易见的问题 - 效率很低，导致的问题大家也都清楚 - 网络堵塞，费用高昂。这个时候就出现了计算扩容的需求

  • 针对传统区块链的扩容有很多方向, 侧链/rollup/新共识/链下扩容等。链下扩容的基础思路是将执行部分放到用户本地或者单独的链下节点进行计算。好处是显而易见的，这里执行计算的机器只有一台或者少数的几台，节约了大量计算资源。而且链下机器可以针对特定计算类型进行优化，达到计算效率的最优化

  • Arweave的永久储存特性可以保证链上储存的数据不可更改性(数据可用性)，这个在链下扩容看来就像图灵机的纸带，所有的合约代码与合约运行状态都可以持续的记录到Arweave上，用户在使用时将合约代码与合约的所有运行状态同步到本地，进行一遍状态计算确保最新状态的有效性后，就可以开始执行自己的操作，最后将最新的合约状态再上传至Arweave完成链下计算的功能

  • 上面说的Arweave提供的这种链下计算方法叫做SmartWeave,是Arweave团队开发的智能合约执行环境。通过上面流程的描述可以发现一个问题，为了获得最新状态数据的有效性保证，用户在本地执行链下计算需要先下载所有历史状态数据并进行一遍验证计算。显然如果历史状态过多或者计算量巨大，用户每次实际使用前都浪费大量时间和算力在同步历史数据与验证最新状态上。KYVE通过整个网络的共识可以保证最新状态的有效性，那么借助KYVE的最新状态数据，用户便可以直接开始自己的链下计算工作了，计算完成后通过KYVE再将状态更新回Arweave。KYVE解决了上传下载过程中数据有效性这个对于链下计算扩容来说至关重要的问题

4.2 数据跨链问题

• 已有数据跨链方案的问题

  • 如今最常用的数据跨链方案大都遵循监控 - 中继模型, 在源链上会有一组合约监控具体的数据状态并生成证明文件，证明文件通过中继网络发送到目标链上。这里可以看到两个问题，源链上的监控者需要持续的监控状态变更，还需要持续生成证明文件，开销是一个问题。更重要的问题是数据信息的中继需要完全信赖中继网络，这也是整个系统最薄弱的地方。

  • 中继或者见证人的存在本质上是为了解决DA信息相互独立隔绝的问题。假如多条链的DA存放在同一个DA层上，那所有信息中继都只是DA层内的信息传递，安全性等同于DA层的安全性，那就只需监控者就可以完成跨链。

• KYVE + Arweave = DA Layer？

  • 最近很火的专注于DA的区块链Celestia最重要的一个Feature就是解决了数据跨链互操作的问题。因为所有其上的区块链都将DA数据存放其中，所以数据跨链本质上就只需要监控这一个角色了，所有中继都是链内的信息传递，这个安全性等同于区块链的安全性。之前我们讨论过KYVE保证了数据的有效性，Arweave保证了数据的可用性，那本质上KYVE+Arweave完全可以作为DA层，达到和Celestia一样的数据跨链和互操作性效果

  • KYVE相较于Celestia的优势在于获取数据的主动性。KYVE是中间件，网络内可以通过治理提案很容易的创建新的数据池来抓取特定区块链的数据。Celestia是被动获取构建于其上的执行层的数据，选择一定程度上是受限的。

  • 还有一点我们不能忘记，KYVE的底层网络Korellia是基于CosmosSDK的独立POS链。所以IBC是完全适用于KYVE的，我想像不出还有哪个网络比KYVE更适合作为Arweave与Cosmos生态的IBC接口。

KYVE架构

5.1 网络设计

• Protocol Layer

  • 协议层架构于链层之上，负责现有KYVE业务(Pools/Fund/Stake/Delegate)

  • 创建和维护各种数据池

  • 数据池内Protocol节点负责上传和验证数据

  • 数据池内Protocol节点负责达成数据有效性共识

  • 数据池内节点发送自身状态到Chain节点

• Chain Layer

  • Tendermint共识, 保存Protocol节点的状态

  • 负责保证Protocol的状态有效性(目前只有KYVE协议)

5.2 网络角色

• Pools

  • 数据池可以被看做是完成收集及验数据工作的最小单位

  • 数据池内包含Funder/Protocol Staker/Protocol Delegator角色

  • 数据池的运行规则依赖runtime模块

  • 针对不同的虚拟机环境需要不同的runtime，但是相同的虚拟机环境可以复用runtime

    • @kyve/evm可以用在Ethereum上，也可以用在EVM兼容链上(Moonbeam/Aurora)

    • 对于Solana则要使用@kyve/solana

• Funder

  • Funder是每个数据池的资金来源，数据池内所有其它角色的盈利来自于Funder

  • Funder是需要使用该数据池数据的项目方或者用户，如果数据池内的funding被耗尽则该数据池会停止工作

  • 目前每个数据池只有100个Funder卡槽，目前Funder没有激励，但是不排除之后针对数据池给与Funder的特权与激励

• Protocol Staker

  • Protocol Staker是数据池内运行节点的角色，真正负责数据池内的上传验证等工作

  • 成为Protocol Staker需要质押kyve代币，如果出现不良行为(离线/上传错误数据/验证数据失误等)会造成节点内质押代币的slash

  • Protocol Staker会按工作量获得kyve代币奖励，奖励和节点代币质押量相关

• Protocol Delegator

  • 如果你不想自己运行Protocol节点, 可以选择作为Delegator, 将kyve代币质押给自己支持的Staker来分享节点的工作收益

  • Protocol Staker的不良行为也会造成在其上质押的kyve的Delegator被slash

  • Protocol Delegator可以帮助筛选出优质节点，共享网络收益

• Chain Staker

  • Chain Staker需要在Korellia网络上运行Chain节点，负责Korellia网络的有效与安全

  • Chain Staker在运行Chain节点时也需要质押kyve代币，类似于其它Cosmos生态链

• Chain Delegator

  • Chain Delegator质押代币给支持的Chain Staker来分享节点工作收益，和其它cosmos生态的链的Stake机制相同

5.3 经济设计

• 金库

  • Protocol节点每次完成bundle proposal都会从Funder处获取奖励，其中1%作为网络费用会被直接扣除到金库

  • Slash的资金也会进入金库

  • 金库资金用于网络的发展与治理

• Slashing

  • 无效上传行为，会造成当事节点20%质押代币的罚没

  • 无效验证行为，会造成当事节点10%质押代币的罚没

  • 超时离线行为，会造成当事节点1%质押代币的罚没

KYVE工作原理

6.1 Data Bundle

• 为了加快KYVE中数据验证的效率，所有数据在被上传前都被打包成bundle，这样在一个验证轮内可以同时处理多个数据，数据流也可以被拆分至多个验证轮中执行。

6.2 Bundle Lifecycle

• 1. 选择一个Uploader

  • 每一个验证轮由选举此轮的Uploader开始

  • Uploader的选择与节点staker的质押量以及Delegation数量相关

• 2. 创建Bundle Proposal

  • 上面选择出来的Uploader按照设定的upload_interval去收集数据

  • 一旦收集到足够数据，数据就被发到buffer进行gzip压缩

  • 最后创建一个bundle proposal之后供其它validator进行验证

• 3. 上传Bundle到Arweave, 将上传信息同步到Kyve网络

  • Uploader将上面打包完成的bundle上传至Arweave

  • 将Arweave返回的上传记录以及其它上传信息同步至网络中

• 4. Validator验证Bundle的有效性

  • 当Uploader将上传记录和其它bundle信息同步到网络后，validator便开始对数据有效性进行验证

  • validator会从Arweave下载原始bundle数据，解压缩，然后把数据解析到原始json格式，然后和源数据进行一次哈希比对

  • 最后validators通过对proposal的投票来达成数据有效性的共识

• 5. 达成网络状态的最终性

  • 如果超过一半的validator确认数据的有效性，则达成网络状态的最终性，此Bundle Id也可以被提供给外部使用

  • 网络内奖励的分配

合作生态

• Arweave

• Solana

• Near

• Avalanche

• Mina

• Cosmos

• Moonbeam

• Aurora

• Octopus

• Celo

• Zilliqa

参考

The KYVE Network | KYVE

五分钟读懂 KYVE：基于 Arweave 的跨链存储中间件

Arweave: The Permanent Storage Experiment - Delphi Digital

A Storage-based Computation Paradigm Enabled by Arweave | by outprog | everFinance | Medium