ohroy/node-noss

这是干嘛的？

懂的都懂。

怎么用？

把 .env.example改成.env，然后里面填上你的私钥和公钥，以及你电脑的cpu个数就可以了。 本项目完全开源，私钥安全自行保证。

pnpm install
pnpm start

node.js 会不会很慢？

事实上不会，因为关键代码是使用的 wasm，是由c语言编译而来。

原理

仅供技术交流，普通用户看不懂也没关系

首先，我的看法是这个noss是非去中心化的，因为它本质上是基于nostr协议，是一个relay server，而relay server并不是去中心化的。 换言之，这个noss本质上就是可以被随意更改的。 它首先会获取eth链上最新的block，然后将这个block的hash作为自己的seq_witness，在这里和eth链上关联，但这种关联是单向的。 本质上，它是在模仿一种链，即每个event都要和上一个event关联，以此实现另类的block chain。但问题是，目前可能用户（韭菜）们并没有留存这个 event chain的意识，或者说官方并没有提供一个很好的途径来实现它。 目前来看，这些event目前存储在其中心化的服务器上，一旦其服务器崩溃或下线，这些数据自然会灰飞烟灭。

电脑之所以嗡嗡响，并非是该项目骗算力或者挖矿的，本质上是 nostr协议的nip13提案，https://github.com/nostr-protocol/nips/blob/master/13.md， 这个nip13最初的设计是用来防止发垃圾消息的。(众所周知，nostr最初是用来做区块链社交的)，它用来防止垃圾消息的思路也非常清奇，叫Pow(Proof of Work)，简单点来说，就是用算力来证明自己不是一个垃圾信息制造者。。。。 我非常不理解，这有什么用，好吧，可能能给发垃圾信息的人造成更多的电力浪费吧。 这个nip13本身十分简单，就是算一下event id的二进制的前面有多少个0，这个算法非常简单，基本上就是进制转换就行。但是，event_id是hash出来的，这个hash比较占用资源，如果要求的0的数量很多，就会导致需要计算很多次 event_id，这个要求0的数量就是difficulty， 本例中，其固定为21。 因此，优化这个hash算法，就是提升解题速度的关键，本项目中，使用了wasm的libsecp256k1用来进行hash运算。

算出来验证码后(即nonce)，再对event进行最后的sig进行签名，然后就可以发送到 noscription进行 mint了。

怎么才算中奖

至于怎么才算mint成功？按照项目方文档的说法是 简单点来是

1. 在下一个eth block出来的时候，取出所有event中seq_witness中的block hash和id为上一个eth block的event。 也就是说网速太慢当下一个eth 区块已经出来，而你还没有求解完成并且提交成功的话，你永远不会中奖

2. 取出所有的event，按event.id 从小到大排序，注意event id和提交事件无关，event id是hash的结果。

3. 依次将所有的event id 进行异或（XOR）操作（上过大学学C语言应该能看明白），然后再异或上当前的block hash(对于该event来说，算是下一个区块)，然后再取余（MOD）所有的事件数量。得出一个余数，

4. 用这个余数当下标，取出对应的event。该event中的pubkey就是中奖的人。

因此，按照其说法，这就是完全的抽奖。

质疑

因为上面的一部分解释，被韭菜们骂了一天了。。。

而且官方下场，也承认自己是中心化的了，但是韭菜们现在的逻辑竟然和官方站在一起了，反倒是给我取了个很搞笑的科学家的称号，彷佛科学家才是他们的敌人， 这真是民不患寡而患不均呀，首先我如果和韭菜是对立的，想靠这个赚钱，那还开源干嘛，关起门来自己爽多好。 事实上，我除了测试代码，根本没挖。原因我上面也说了，这个项目本身就是中心化的。

但是我得澄清下，虽然是中心化的，但是这个项目也不一定是个骗局，也许只是项目方没有做好。 从技术上来讲， event chain是可以被追溯，可以防止篡改的。前期是项目方公开所有的event，并且允许韭菜们随时同步。 而且，不仅要公开所有的event chain，也要公开所有不在chain中，即没有中将的韭菜们提交event的，以供社区验算中奖结果。（按照上文提到的算法）

我相信这也是他们正在努力的方向，但至少目前，他们还没有做到，而且里这一步还很远。。

希望韭菜们别再骂我了，我不喜欢中心化的东西。所以不会是你们的竞争对手。