天下皆知美之為美，斯惡已。皆知善之為善，斯不善已。故有無相生，難易相成，長短相較，高下相傾，音聲相和，前後相隨。是以聖人處無為之事，行不言之教；萬物作焉而不辭，生而不有。為而不恃，功成而弗居。夫唯弗居，是以不去。

—— "Tao Te Ching, Chapter 0x02"

0x01 Background

In Vitalik's "Decentralized Society: Finding the Soul of Web3", a cool and fascinating picture of the future is presented.

With Web3, we have the opportunity to construct a Web3 Society based on "new building blocks" such as DID, Coin, NFT, and SBT.

What Vitalik proposes, however, is a general Web3 Society. Under this background, we can fork out the branch of the subdivision field. For example, what we need to discuss today is the "Decentralized Developer Society" composed of Developers.

Next, we will use the idea of "beginning with the end in mind" to discuss if there is a "decentralized developer society" in the future, what are its key principles? In other words, what matters most?

• **Benefits💰: **Realize the developer's "earning for work"

• **Re-Education📚: **Achieving a "good upgrade path" for developers

• **Globalization🌏: **Helping developers get rid of geographical restrictions

• **Opportunity 😘 : **Helps developers build their personal brand

0x02 Realize the developer's "earning for work"

The first and foremost point is that the "decentralized developer society" needs to realize the developer's "earning for work". Otherwise there will be such an unfortunate situation for core-js author:

"Open source core-js was probably the biggest mistake of my life."

—— https://www.oschina.net/news/228389/corejs-maintainer-so-whats-next#:~:text=core-js 作者Denis Pushkarev,和遭遇，以及心态变化。

Fortunately, Web3 technology provides developers with the opportunity to upgrade the original open source model of "purely generating power for love"—independent developers have a cool idea, and develop a cool Web3 project on this basis. You can use this project to participate in Hackathon, apply for Grant, obtain financing, and so on. In the previous Web2 world, it was difficult for developers to gain this level of voice and initiative.

In short, **Web3 Society itself is more developer-friendly. **

0x03 Implement a "good upgrade path" for developers

Secondly, the "decentralized developer society" must realize the "good upgrade path" for developers.

What is a "good upgrade path"?

A key point is that if the member is willing and able enough, then he can master his "upgrade" completely autonomously. For example, in this system, as long as the ability is sufficient, then level skipping is completely allowed.

The opposite example is the "seniority ranking" system, where "level" is strongly related to "time" rather than "ability". This system runs counter to the spirit of Web3.

The second key point is that if the **upgrade path can be "gradually promoted". **

The escalation path for startups in the Web2 world is steep, often requiring a large sum of money to start a startup. Therefore, in the traditional world, for the vast majority of people, they will never start a business in their lifetime.

However, in the Web3 Society, a smoother "upgrade path" has spontaneously formed:

+-----------------+    +--------------------+
| Technical Study |----|Working On Bounties |---- Got Money
+-----------------+    +--------------------+
     ↓↓↓
+---------------+
| Amazing Ideas |
+---------------+
     ↓↓↓
+----------------+
| Join Hackathon |---- Got Money
+----------------+
     ↓↓↓
+-----------------+
| Apply for Grant |---- Got Money
+-----------------+
    ↓↓↓
+-----------------+
| Financing |---- Got Money
+-----------------+

**In each stage, Buidlers have the opportunity to get money, so as to proceed to the next stage, thus achieving the "flywheel effect". What NonceGeekDA has to do is to make this path clearer, more explicit, and developer-friendly. **

0x04 Help developers get rid of geographical restrictions

**It seems to be common sense that the long-term income of workers is strongly bound to the region where they are located. **

When the regional economy declines, no matter how high the level of workers is, their income will inevitably be affected; in addition, for workers of the same level, their income levels vary greatly in different regions.

Therefore, in the past, capable workers tended to go to places with the highest income levels—but higher income levels often also meant higher living costs, such as Silicon Valley.

The global collaboration brought about by Web3 and the open source paradigm can theoretically break this traditional situation - break the strong relationship between the developer's work and the place of work, achieve geographic freedom and time freedom, and allow developers to enjoy the "geographic arbitrage dividend" .

However, for most developers, especially domestic developers, there are still many obstacles to achieve global links, for example, insufficient language skills make it difficult to communicate smoothly, lack of linking institutions with overseas developers and organizations, etc. wait.

** Therefore, it is an important mission of NonceGeekDAO to help developers get rid of geographical restrictions, realize global links, create More & More Serendipity through global links, and finally achieve rapid growth. **

0x05 Help developers build their personal brand

"Personal branding" seems to have become a cliché in today's era, but few people really understand the law behind "personal branding": **"Always attract, not pursue". **

• When looking for a job, always attract rather than pursue;

• When looking for a partner, always attract rather than pursue

• ...

When the world facing you gradually opens up, you will find that only attraction is the only correct answer. If you use pursuit, then your daily attention will be exhausted in the pursuit; but if you learn to attract, even if you just master how to write Github Personal README correctly, then you also have a 24 h automatic operation There is nothing more cost-effective and more important than attracting machines.

**How to help developers build their personal brands, especially through the early days when personal brands lack positive feedback? It will be a proposition that NonceGeekDAO will continue to explore. **

0x06 Epilogue

NonceGeekDAO firmly believes that, as Developers DAOs / Orgs, it is very important to be developer-oriented and focus on developer rights. On the basis of the original intention, follow the inevitable trend and do the right thing. In the long run, the world will definitely give positive feedback.

Best wishes for all Buidlers/Developers/Orgs/DAOs working for the better world!

In the future, the theme of "Building a decentralized developer society" will be elaborated in more detail through a series of articles, including two levels of concept and practice.

Authors: Leeduckgo, Ningbo Wang, Junfeng Chen @ NonceGeekDAO

Translator: msfew

We've been evolving from binary to assembly to various high-level languages. Smart contracts, too, have taken a big step forward from Bitcoin's Script to Ethereum's Solidity, but can Solidity take over the world? In fact, the endless security issues that have been plaguing us have largely limited the development of the industry as a whole. "Security" is more important than ever in the financial scenario, especially in the DeFi era, and we cannot turn a blind eye to these issues. If the blockchain industry continues to evolve, there will inevitably be better smart contract languages coming out.

With these premises in mind, a new smart contract language, Move, was designed for "resource" oriented programming. I personally think that "resource-oriented programming" is a change in the smart contract language, and frankly, it is a big step forward.

——jolestar

——https://starcoin.org/zh/developer/blog/starcoin_move_resource

——https://mirror.xyz/jolestar.eth/sQ0nMCO3eNig6gCzqQO7xew1mn8oUi1-rKtfZKmGlNI

This series will explain the Move language and the development of the Move dApp, and the computer principles behind it, using Starcoin as an example.

For a full update of this series, see:

https://github.com/WeLightProject/Web3-dApp-Camp/tree/main/move-dapp

Assignments:

https://github.com/WeLightProject/Web3-dApp-Camp/discussions/categories/projects-others

1 Node Start-up

Download the latest distribution of the Starcoin node program (for MacOS just copy it to the /usr/local/bin directory):

https://github.com/starcoinorg/starcoin/releases

Here is a demonstration of how to start a node based on the Starcoin network:

https://starcoinorg.github.io/starcoin-cookbook/docs/getting-started/setup/

TLDR version - key commands:

# Start a local dev node
$ starcoin -n dev
# Start a local dev node and open the console at the same time. The -d parameter ensures that historical data is kept each time the console is opened instead of reopened
$ mkdir [folder_name]
$ cd [folder_name]
$ pwd
$ starcoin -d [path_to_your_data_folder] -n dev console

starcoin Console commands.

# Designated accounts receive test tokens
starcoin% dev get-coin 0xb7c46353c6c0e3a2559d5b12cad981e4 -v 100STC
# Account list
starcoin% account list
# Single account status view
starcoin% account show 0xb7c46353c6c0e3a2559d5b12cad981e4
# Create new account
starcoin% account create -p [pwd]

2 The first Move contract -- MyCounter

Minimum practicable example:

https://github.com/starcoinorg/starcoin-cookbook/blob/main/examples/my-counter

module MyCounterAddr::MyCounter {
     use StarcoinFramework::Signer;

     struct Counter has key, store {
        value:u64,
     }
     public fun init(account: &signer){
        move_to(account, Counter{value:0});
     }
     public fun incr(account: &signer) acquires Counter {
        let counter = borrow_global_mut<Counter>(Signer::address_of(account));
        counter.value = counter.value + 1;
     }

     public(script) fun init_counter(account: signer){
        Self::init(&account)
     }

     public(script) fun incr_counter(account: signer)  acquires Counter {
        Self::incr(&account)
     }
}

MyCounter source code analysis

A module is a set of functions and structures packaged together at a specific address. To use script, you need to run it with a published module or standard library, which is itself a set of modules published at address 0x1.

module MyCounterAddr::MyCounter{ } then a module is created under this MyCounterAddr address (corresponding to MyCounterAddr = "0xb7c46353c6c0e3a2559d5b12cad981e4" under Move.toml).

use StarcoinFramework::Signer, is using the Signer module under the standard library. Signer is a native Resource-like non-reproducible type that contains the address of the sender of the transaction. One of the reasons for introducing the signer type was to explicitly show which functions require sender privileges and which do not. Thus, functions cannot trick users into unauthorized access to their Resource. See source code for details.

struct Counter has key, store {
        value:u64,
     }

A structure called Counter is defined using struct, modified by both key,store constraints, and Move has a flexible type system where each type can be modified by four constraints. These four constraints, which we call abilities, define whether the type's values can be copied, dropped, and stored. The four abilities constraints are: Copy, Drop, Store and Key.

Their functions are.

• Copy - The modified value can be copied.

• Drop - The modified value can be dropped at the end of the scope.

• Key - the modified value can be accessed as a key to the global state.

• Store - The modified value can be stored to the global state.

The key,store modifier here means that it cannot be copied, discarded or reused, but it can be safely stored and transferred.

The following is the definition:

public fun init(account: &signer){
    move_to(account, Counter{value:0});
}
public fun incr(account: &signer) acquires Counter {
    let counter = borrow_global_mut<Counter>(Signer::address_of(account));
    counter.value = counter.value + 1;
}

The definition format is:

public fun functionName(parameter: parameter type){ }

The move functions are private by default and can only be accessed in the module where they are defined. The keyword public will change the default visibility of the function and make it public, i.e. accessible from outside.

The init method argument is a &signer, meaning that the method must be legally signed by an account before it can be called, and move_to is an original language for move, which serves to publish and add Counter resources to the signer's address. move's account model, code and data are stored under an account address.

The following is a list of common original phrases

• move_to< T >(&signer, T): Publish, add a resource of type T to the address of signer.

• move_from< T >(addr: address): T - removes a resource of type T from under the address and returns this resource.

• borrow_global< T >(addr: address): &T - Returns an immutable reference to a resource of type T at the address.

• borrow_global_mut< T >(addr: address): &mut T - Returns a mutable reference to a resource of type T at address.

• exists< T >(address): bool: Determines if there is a resource of type T under address.

The incr method argument is also a &signer, meaning that the method must be legally signed by an account before it can be called,

The keyword acquires, placed after the function return value, is used to explicitly define all the Resources acquired by this function.

Signer::address_of(account) gets the address from the signer

borrow_global_mut is described above, variable borrow to address under the resource Counter, and then the value under the Counter structure for +1 operation.

The following two methods are script methods, what is the difference between it and the above two functions?

• public fun: method can be called from any module.

• public(script) fun: script function is the entry method in the module, indicating that the method can be called by initiating a transaction from the console, just like a locally executed script

The next version of Move will replace public(script) fun with public entry fun

Self represents its own module.

  public(script) fun init_counter(account: signer){
        Self::init(&account)
     }

     public(script) fun incr_counter(account: signer)  acquires Counter {
        Self::incr(&account)
     }

2.1 Compilation

Download the source code for the first example at:

$ git clone git@github.com:WeLightProject/Web3-dApp-Camp.git
$ cd Web3-dApp-Camp/move-dapp/my-counter

The package management tool for Move is the Move Package Manager (mpm), which is similar to Rust's Cargo or Node's NPM. You can create a new project with mpm package new my-counter, the typical directory structure is:

my-counter
├── Move.toml
└── sources
    └── MyCounter.move

• sources is used to archive Move's modules, which are similar to class files in Java.

• Move.toml - used to store configuration files: including the original package data, dependencies and named addresses.

• The above files constitute a Move Package. For more details on Move Package management refer to the documentation

Change the address in move.toml to the one you use for deployment.

Compiled with:

$ mpm release

Next you will see your compiled binaries in the release folder.

2.2 Console Deployment

Deployment is done by executing the following command in the Starcoin Console:

starcoin% dev deploy [path to blob] -s [addr] -b

-s means --sender,-b means --blocking, which means blocking and waiting for command execution to finish

If the account is locked, use the unlock command to unlock it.

account unlock [addr] -p [pwd]

where pwd is the password created in 1.2.

After successful deployment you can see:

💡 It is important to note that in Move the code is stored on a personal address, not a public address like in Ethereum. So no new address is created after the contract is deployed, when we want to call the contract we need to use the address of the person who deployed the contract + the contract name to call the contract.

2.3 Console calls

https://starcoinorg.github.io/starcoin-cookbook/docs/move/interacting-with-the-contract

1. Call the init_counter script function to initialize the resource.

starcoin% account execute-function --function {MyCounterAddr-in-Move.toml}::MyCounter::init_counter -s 0x23dc2c167fcd16e28917765848e189ce -b

Among them:

• {MyCounterAddr-in-Move.toml}::MyCounter::init_counteris the complete address on the function onchain, including the address where the contract is located + package name + function name.

• -s means --sender,-b means --blocking, which means blocking and waiting for command execution to finish

1. View Counter resources

starcoin% state get resource 0x23dc2c167fcd16e28917765848e189ce 0x23dc2c167fcd16e28917765848e189ce::MyCounter::Counter

The data of the contract in Move is called Resource(resource), and since reading data does not change the state on the chain, no -s -b is needed, no transactions are executed, and no state is consumed.

Interested students can try to call incr_counter and check again if Counter is +1.

作者： 李大狗、王宁波、陈俊锋 @ NonceGeekDAO

我们从二进制到汇编到各种高级语言，一直都在发展。智能合约也一样，从比特币的Script到以太坊的Solidity，往前跨了一大步，但是，Solidity能包打天下了吗？事实上，层出不穷的安全问题一直在困扰我们，在很大程度上限制了整个行业的发展。「安全」在金融场景，尤其是DeFi时代，比以往任何时候都更加重要，这些问题我们不能视而不见。如果区块链行业继续发展，势必会有更好的智能合约语言出来。

在这些大前提下，新的智能合约语言Move被设计出来了。Move是面向「资源」编程的。我个人认为，「面向资源编程」是智能合约语言的一个变革，说白了，智能合约语言又往前迈了一大步。

——jolestar

——https://starcoin.org/zh/developer/blog/starcoin_move_resource

——https://mirror.xyz/jolestar.eth/sQ0nMCO3eNig6gCzqQO7xew1mn8oUi1-rKtfZKmGlNI

本系列将以 Starcoin 为例，讲解 Move 语言以及 Move dApp 的开发，及其背后的计算机原理。

本系列的全文更新中，见：

https://github.com/WeLightProject/Web3-dApp-Camp/tree/main/move-dapp

同步的打卡任务：

https://github.com/WeLightProject/Web3-dApp-Camp/discussions/categories/projects-others

1 节点启动

下载最新的发行版 Starcoin 节点程序（MacOS 将其拷贝至/usr/local/bin目录即可）：

https://github.com/starcoinorg/starcoin/releases

在此以Starcoin网络为基础，展现如何启动一个节点：

https://starcoinorg.github.io/starcoin-cookbook/docs/getting-started/setup/

太长不看版——关键命令合集：

# 启动一个本地 dev 节点
$ starcoin -n dev
# 启动一个本地 dev 节点的同时打开控制台，-d 参数可以确保每次打开控制台时都保有历史的数据而不是重开
$ mkdir [folder_name]
$ cd [folder_name]
$ pwd
$ starcoin -d [path_to_your_data_folder] -n dev console

starcoin 控制台命令：

# 指定账户获得测试代币
starcoin% dev get-coin 0xb7c46353c6c0e3a2559d5b12cad981e4 -v 100STC
# 账户列表
starcoin% account list
# 单一账户情况查看
starcoin% account show 0xb7c46353c6c0e3a2559d5b12cad981e4
# 创建新账户
starcoin% account create -p [pwd]

2 第一个 Move 合约 —— MyCounter

最小可实践例子：

https://github.com/starcoinorg/starcoin-cookbook/blob/main/examples/my-counter

module MyCounterAddr::MyCounter {
     use StarcoinFramework::Signer;

     struct Counter has key, store {
        value:u64,
     }
     public fun init(account: &signer){
        move_to(account, Counter{value:0});
     }
     public fun incr(account: &signer) acquires Counter {
        let counter = borrow_global_mut<Counter>(Signer::address_of(account));
        counter.value = counter.value + 1;
     }

     public(script) fun init_counter(account: signer){
        Self::init(&account)
     }

     public(script) fun incr_counter(account: signer)  acquires Counter {
        Self::incr(&account)
     }
}

MyCounter 源码分析

module 是发布在特定地址下的打包在一起的一组函数和结构体。使用script时需要与已发布的module或标准库一起运行，而标准库本身就是在 0x1 地址下发布的一组module。

module MyCounterAddr::MyCounter{ } 则在该MyCounterAddr地址下(对应Move.toml下的MyCounterAddr = "0xb7c46353c6c0e3a2559d5b12cad981e4")创建一个module。

use StarcoinFramework::Signer，是使用标准库下的Signer module，Signer 是一种原生的类似 Resource 的不可复制的类型，它包含了交易发送者的地址。引入signer类型的原因之一是要明确显示哪些函数需要发送者权限，哪些不需要。因此，函数不能欺骗用户未经授权访问其 Resource。具体可参考源码。

struct Counter has key, store {
        value:u64,
     }

使用struct定义了一个叫做Counter的结构体，同时被 key,store两种限制符修饰，Move的类型系统灵活，每种类型都可以被四种限制符所修饰。这四种限制符我们称之为 abilities，它们定义了类型的值是否可以被复制、丢弃和存储。 这四种 abilities 限制符分别是: Copy, Drop, Store 和 Key.

它们的功能分别是：

• Copy - 被修饰的值可以被复制。

• Drop - 被修饰的值在作用域结束时可以被丢弃。

• Key - 被修饰的值可以作为键值对全局状态进行访问。

• Store - 被修饰的值可以被存储到全局状态。

这里用key,store修饰，则表示它不能被复制，也不能被丢弃或重新使用，但是它却可以被安全地存储和转移。

下面则是定义的方法，

public fun init(account: &signer){
    move_to(account, Counter{value:0});
}
public fun incr(account: &signer) acquires Counter {
    let counter = borrow_global_mut<Counter>(Signer::address_of(account));
    counter.value = counter.value + 1;
}

定义格式则是:

public fun 函数名(参数：参数类型){ }

move函数默认是私有函数，只能在定义它们的模块中访问。关键字 public 将更改函数的默认可见性并使其公开，即可以从外部访问。

init方法参数是一个&signer，意味着该方法必须是一个账户合法签名过后才可以调用，move_to则是move的一个原语，作用是发布、添加Counter资源到 signer 的地址下。Move的账户模型，code和data是存储在一个账户地址下的。

下面是列举的常用原语

• move_to< T >(&signer, T)：发布、添加类型为 T 的资源到 signer 的地址下。

• move_from< T >(addr: address): T - 从地址下删除类型为 T 的资源并返回这个资源。

• borrow_global< T >(addr: address): &T - 返回地址下类型为 T 的资源的不可变引用。

• borrow_global_mut< T >(addr: address): &mut T - 返回地址下类型为 T 的资源的可变引用。

• exists< T >(address): bool：判断地址下是否有类型为 T 的资源。。

incr方法参数也是一个&signer，意味着该方法必须是一个账户合法签名过后才可以调用,

关键字 acquires，放在函数返回值之后，用来显式定义此函数获取的所有 Resource。

Signer::address_of(account) 从签名者中拿到address

borrow_global_mut上面有介绍到，可变借用到address下到resource Counter，然后将Counter结构体下的value进行+1操作。

这下面的两个方法则是script方法,它与上面两个函数有什么区别呢？

• public fun : 方法可以在任何模块中被调用。

• public(script) fun：script function 是模块中的入口方法，表示该方法可以通过控制台发起一个交易来调用，就像本地执行脚本一样

下个版本的 Move 会用 public entry fun 替代 public(script) fun

Self则是代表自身module。

  public(script) fun init_counter(account: signer){
        Self::init(&account)
     }

     public(script) fun incr_counter(account: signer)  acquires Counter {
        Self::incr(&account)
     }

2.1 编译

下载第一个实例的源码：

$ git clone git@github.com:WeLightProject/Web3-dApp-Camp.git
$ cd Web3-dApp-Camp/move-dapp/my-counter

Move的包管理工具为Move Package Manager(mpm),它类似于Rust的Cargo或者Node的NPM。 可以通过mpm package new my-counter来创建一个新项目，典型的目录结构为:

my-counter
├── Move.toml
└── sources
    └── MyCounter.move 

• sources用来存档Move的模块,它类似于与Java中的类文件。

• Move.toml-用来存放配置文件：包括包的原数据、依赖和命名地址。

• 上述文件构成一个Move包(Move Package) 更详细的Move包管理参考文档

修改move.toml中的地址为你用来部署的地址。

编译：

$ mpm release

接下来会在release文件夹中，看到你编译好的二进制文件。

2.2 控制台部署

在 Starcoin Console 中执行如下命令即可部署：

starcoin% dev deploy [path to blob] -s [addr] -b

-s 即--sender,-b即--blocking，表示阻塞等待命令执行完成

如果遇到账户被锁，用 unlock命令解锁即可。

account unlock [addr] -p [pwd]

其中pwd即是在1.2中创建的密码。

部署成功后能看到：

💡需要注意的是，在Move中代码存储在个人的地址上，而非像以太坊那样的公共地址上。因此合约部署后并不会创建新地址，当我们想要调用合约时需要采用部署合约人的地址+合约名来调用该合约。

2.3 控制台调用

https://starcoinorg.github.io/starcoin-cookbook/docs/move/interacting-with-the-contract

1. 调用 init_counter 脚本函数来初始化资源。

starcoin% account execute-function --function {MyCounterAddr-in-Move.toml}::MyCounter::init_counter -s 0x23dc2c167fcd16e28917765848e189ce -b

其中:

• {MyCounterAddr-in-Move.toml}::MyCounter::init_counter为完整的函数链上地址，包括合约所在地址+包名+函数名。

• -s 即--sender,-b即--blocking，表示阻塞等待命令执行完成

1. 查看Counter资源

starcoin% state get resource 0x23dc2c167fcd16e28917765848e189ce 0x23dc2c167fcd16e28917765848e189ce::MyCounter::Counter

在Move中合约的数据被称为资源(resource)，由于读取数据不改变链上状态，因此不需要-s -b，不会执行交易，也不消耗状态。

感兴趣的同学可以试着调用incr_counter，并再次查看Counter是否+1。

国内用户请加微信：19726581

Authors: Fenix, msfew

0x00 Goal

Buidl a decentralized Staking dApp.

This example also corresponds to Challenge 0x01 in SpeedrunEthereum (an official Ethereum developer challenge):

https://speedrunethereum.com/challenge/decentralized-staking

An example of one of these completions can be found at:

Contract: https://rinkeby.etherscan.io/address/0x4707468C95558E9B2F339c2A41DAEF483Ce11104 dApp: https://duckgo_staking.surge.sh/

0x01 What is Staking

Staking, which translates to pledge, staking mining, or staking of interest, is the algorithm used to generate new blocks, and is derived from Proof of Stake.

If you're familiar with how Bitcoin works, you're probably familiar with Proof of Work (PoW). This mechanism allows transactions to be collected into blocks. These blocks are then linked together to create a blockchain.

Specifically, miners compete to solve complex mathematical puzzles, and whoever solves the puzzle first is entitled to add the next block to the blockchain. Proof of workload has proven to be a very powerful mechanism to facilitate consensus in a decentralized manner. The problem is that this mechanism involves a lot of arbitrary computation. Miners are scrambling to solve the puzzle just to maintain network security and nothing else.

Moving on to proof of stake, the main idea is that participants can lock in tokens (their "pledged interest") and the protocol will randomly assign rights to one of them for verification of the next block at a given time interval. Usually, the probability of being selected is proportional to the number of tokens: the more tokens locked, the better the chances.

In the cryptocurrency market, mining has been gradually replaced by staking in recent years, with the benefit of lower power consumption and passive income than the former.

0x02 Speed Run Web3

Some students may not have experience with web3 related development, so here is a speed run on your behalf to facilitate a quick introduction to the development on Ether.

Prerequisites

• metamask Wallet

Environment

• nodejs

• yarn

• git

• vscode

Tech Stack

• Framework: scaffold-eth

• Frontend: react

• Contract Development: hardhat

Step 1: Scaffolding

https://github.com/scaffold-eth/scaffold-eth

git clone https://github.com/scaffold-eth/scaffold-eth.git
cd scaffold-eth
yarn install

Step 2: Start a local network

cd scaffold-eth
yarn chain

Step 3: Deploy Smart Contracts

cd scaffold-eth
yarn deploy

Step 4: Open the front-end page

cd scaffold-eth
yarn start

• Technology Stack

  • Top Level Technology Stack

    • solidity contract programming language

    • hardhat local development test chain

    • react front-end

    • etherseth api sdk

    • antd front-end components ui

  • Libraries & Components & Services

    • Eth-components

    • Eth-services

    • Command Line

  • Underlying Foundation

    • the graph

    • tenderly

    • etherscan

    • rpc

    • blocknative

    • L2/Sidechain Services

      • Arbitrum

      • Optimism

      • Graph Node

  • Examples

    • General

      • simple dao

      • Diamond Standard

      • Meta-Multi-Sig Wallet

      • Minimal Proxy

      • Minimum Viable Payment Channel

      • PunkWallet.io

      • Push The Button - Multi-player Turn Based Game

      • radwallet.io

      • Signator.io

      • Simple Stream

      • Token Allocator

      • Streaming Meta Multi Sig

    • DeFi

      • Bonding Curve

      • rTokens

      • Quadratic Funding

      • Uniswapper

      • Lender

      • Aave Flash Loans Intro

      • Aave Ape

      • DeFi Subgraphs

    • NFT

      • Simple NFT

      • Simple ERC-1155 NFT

      • Chainlink VRF NFT

      • Merkle Mint NFT

      • Nifty Viewer

      • NFT Auction

      • NFT Signature Based Auction

    • Security

      • Honeypot

      • Re-entrancy Attack

      • Denial of Service

    • Infrastructure

      • ChainLink

    • Layer2

      • Optimism Starter Pack

      • Optimism NFT

      • xNFT.io

0x03 Staking Contract

We all know that the most important part of dApp development is writing smart contracts, so let's analyze the basic format of a Staking contract.

Pledge (stake) a certain amount of tokens (threshold) within a certain time (deadline). After the expiration date, you can transfer (execute) the tokens to another contract, or withdraw (withdraw) the tokens.

So we abstracted out three key functions.

1. stake()

2. execute()

3. withdraw()

scaffold-eth also provides us with such a scaffold, just pull down the code and we will build on it step by step this time.

https://github.com/scaffold-eth/scaffold-eth-challenges

git clone https://github.com/scaffold-eth/scaffold-eth-challenges.git
cd scaffold-eth-challenges
git checkout challenge-1-decentralized-staking
yarn install

Then open three terminal windows and execute the following three commands:

yarn start

yarn deploy --reset

0x04 Live Coding

4.1 stake

• Key point 1: Stake a certain amount of eth at a time.

pragma solidity 0.8.4;

import "hardhat/console.sol";
import "./ExampleExternalContract.sol";

contract Staker {
    mapping(address => uint256) public balances;

    event Stake(address indexed staker, uint256 amount);

    function stake() public payable {
        balances[msg.sender] += msg.value;
        emit Stake(msg.sender, msg.value);
    }
}

• Key point 2, deploy the script to remove the constructor's parameters

// deploy/01_deploy_staker.js
// ....

await deploy('Staker', {
  // Learn more about args here: https://www.npmjs.com/package/hardhat-deploy#deploymentsdeploy
  from: deployer,
  // args: [exampleExternalContract.address],
  log: true,
});

//...

• Key Point 3, Deployment

yarn deploy --reset

• Key point 4, airdrop some test coins

• Key point 5, test staking

4.2 execute

The funds raised are transferred to another contract after certain conditions are met.

• Key point 1, another contract

contract ExampleExternalContract {

  bool public completed;

  function complete() public payable {
    completed = true;
  }

}

It's simple, there is a flag to indicate whether it is finished or not.

• Key point 2, the constructor

In the stake contract, to bring in this contract, there is a constructor.

ExampleExternalContract public exampleExternalContract;

constructor(address exampleExternalContractAddress) public {
        exampleExternalContract = ExampleExternalContract(
            exampleExternalContractAddress
        );
}

• Key point 3, initialize when deploying

// deploy/01_deploy_staker.js
// ....

await deploy('Staker', {
  // Learn more about args here: https://www.npmjs.com/package/hardhat-deploy#deploymentsdeploy
  from: deployer,
  args: [exampleExternalContract.address],
  log: true,
});

//...

• Key Point 4, Staking Limit

uint256 public constant threshold = 1 ether;

• Key point 5, transfer to the second contract.

    function execute() public {
        uint256 contractBalance = address(this).balance;

        // check the contract has enough ETH to reach the treshold
        require(contractBalance >= threshold, "Threshold not reached");

        // Execute the external contract, transfer all the balance to the contract
        // (bool sent, bytes memory data) = exampleExternalContract.complete{value: contractBalance}();
        (bool sent, ) = address(exampleExternalContract).call{
            value: contractBalance
        }(abi.encodeWithSignature("complete()"));
        require(sent, "exampleExternalContract.complete failed");
    }

• The final code is as follows

// SPDX-License-Identifier: MIT
pragma solidity 0.8.4;

import "hardhat/console.sol";
import "./ExampleExternalContract.sol";

contract Staker {
    ExampleExternalContract public exampleExternalContract;

    mapping(address => uint256) public balances;

    uint256 public constant threshold = 1 ether;

    event Stake(address indexed staker, uint256 amount);

    constructor(address exampleExternalContractAddress) public {
        exampleExternalContract = ExampleExternalContract(
            exampleExternalContractAddress
        );
    }

    function stake() public payable {
        balances[msg.sender] += msg.value;
        emit Stake(msg.sender, msg.value);
    }

    function execute() public {
        uint256 contractBalance = address(this).balance;

        require(contractBalance >= threshold, "Threshold not reached");

        (bool sent, ) = address(exampleExternalContract).call{
            value: contractBalance
        }(abi.encodeWithSignature("complete()"));
        require(sent, "exampleExternalContract.complete() failed");
    }
}

• Deployment

yarn deploy --reset

• Airdrop test coins

• stake some coins reach the limit

• test execute

4.3 withdraw

Withdrawing the staked money is relatively simple - just transfer the money out.

    function withdraw() public {
        uint256 userBalance = balances[msg.sender];

        require(userBalance > 0, "You don't have balance to withdraw");

        balances[msg.sender] = 0;

        (bool sent, ) = msg.sender.call{value: userBalance}("");
        require(sent, "Failed to send user balance back to the user");
    }

• The complete code is as follows

// SPDX-License-Identifier: MIT
pragma solidity 0.8.4;

import "hardhat/console.sol";
import "./ExampleExternalContract.sol";

contract Staker {
    ExampleExternalContract public exampleExternalContract;

    mapping(address => uint256) public balances;

    uint256 public constant threshold = 1 ether;

    uint256 public deadline = block.timestamp + 30 seconds;

    event Stake(address indexed sender, uint256 amount);

    constructor(address exampleExternalContractAddress) public {
        exampleExternalContract = ExampleExternalContract(
            exampleExternalContractAddress
        );
    }

    function stake() public payable {
        balances[msg.sender] += msg.value;

        emit Stake(msg.sender, msg.value);
    }

    function execute() public {
        uint256 contractBalance = address(this).balance;

        require(contractBalance >= threshold, "Threshold not reached");

        (bool sent, ) = address(exampleExternalContract).call{
            value: contractBalance
        }(abi.encodeWithSignature("complete()"));
        require(sent, "exampleExternalContract.complete failed");
    }

    function withdraw() public {
        uint256 userBalance = balances[msg.sender];

        require(userBalance > 0, "You don't have balance to withdraw");

        balances[msg.sender] = 0;

        (bool sent, ) = msg.sender.call{value: userBalance}("");
        require(sent, "Failed to send user balance back to the user");
    }
}

• Deployment

yarn deploy --reset

• Airdrop test coins

• stake some coins

• test withdraw

4.4 Add time or staking expiration restrictions

There are two criteria to judge here

The first is whether the time has been reached, and the other is whether the pledge has been completed.

• Whether the first one is completed or not, just go directly to the mark of the other contract

        modifier stakeNotCompleted() {
        bool completed = exampleExternalContract.completed();
        require(!completed, "staking process is already completed");
        _;
    }

• Is the second one up to time?

  • The first is to have a deadline variable

  uint256 public deadline = block.timestamp + 60 seconds;
  

  • Then there is also a timeLeft function

          function timeLeft() public view returns (uint256 timeleft) {
          if (block.timestamp >= deadline) {
              return 0;
          } else {
              return deadline - block.timestamp;
          }
      }
  

  • Next is the deadlineReached function

          modifier deadlineReached(bool requireReached) {
          uint256 timeRemaining = timeLeft();
          if (requireReached) {
              require(timeRemaining == 0, "deadline is not reached yet");
          } else {
              require(timeRemaining > 0, "deadline has already reached");
          }
          _;
      }
  

• How to modify these functions

  • stake

      function stake() public payable deadlineReached(false) stakeNotCompleted {
          balances[msg.sender] += msg.value;
          emit Stake(msg.sender, msg.value);
      }
  

  • execute function

      function execute() public stakeNotCompleted deadlineReached(false) {
          uint256 contractBalance = address(this).balance;
  
          require(contractBalance >= threshold, "Threshold not reached");
  
          (bool sent, ) = address(exampleExternalContract).call{
              value: contractBalance
          }(abi.encodeWithSignature("complete()"));
          require(sent, "exampleExternalContract.complete() failed");
      }
  

  • withdraw function

      function withdraw() public deadlineReached(true) stakeNotCompleted {
          uint256 userBalance = balances[msg.sender];
  
          require(userBalance > 0, "You don't have balance to withdraw");
  
          balances[msg.sender] = 0;
  
          (bool sent, ) = msg.sender.call{value: userBalance}("");
          require(sent, "Failed to send user balance back to the user");
      }
  

• Functions that can be called by external contracts

    receive() external payable {
        stake();
    }

The final code is as follows:

// SPDX-License-Identifier: MIT
pragma solidity 0.8.4;

import "hardhat/console.sol";
import "./ExampleExternalContract.sol";

contract Staker {
    ExampleExternalContract public exampleExternalContract;

    mapping(address => uint256) public balances;

    uint256 public constant threshold = 1 ether;

    event Stake(address indexed staker, uint256 amount);

    uint256 public deadline = block.timestamp + 60 seconds;

    constructor(address exampleExternalContractAddress) public {
        exampleExternalContract = ExampleExternalContract(
            exampleExternalContractAddress
        );
    }

    modifier stakeNotCompleted() {
        bool completed = exampleExternalContract.completed();
        require(!completed, "staking process is already completed");
        _;
    }

    modifier deadlineReached(bool requireReached) {
        uint256 timeRemaining = timeLeft();
        if (requireReached) {
            require(timeRemaining == 0, "deadline is not reached yet");
        } else {
            require(timeRemaining > 0, "deadline has already reached");
        }
        _;
    }

    function timeLeft() public view returns (uint256 timeleft) {
        if (block.timestamp >= deadline) {
            return 0;
        } else {
            return deadline - block.timestamp;
        }
    }

    function stake() public payable deadlineReached(false) stakeNotCompleted {
        balances[msg.sender] += msg.value;
        emit Stake(msg.sender, msg.value);
    }

    function execute() public stakeNotCompleted deadlineReached(false) {
        uint256 contractBalance = address(this).balance;

        require(contractBalance >= threshold, "Threshold not reached");

        (bool sent, ) = address(exampleExternalContract).call{
            value: contractBalance
        }(abi.encodeWithSignature("complete()"));
        require(sent, "exampleExternalContract.complete() failed");
    }

    function withdraw() public deadlineReached(true) stakeNotCompleted {
        uint256 userBalance = balances[msg.sender];

        require(userBalance > 0, "You don't have balance to withdraw");

        balances[msg.sender] = 0;

        (bool sent, ) = msg.sender.call{value: userBalance}("");
        require(sent, "Failed to send user balance back to the user");
    }

    receive() external payable {
        stake();
    }
}

• Deployment

yarn deploy --reset

• Testing

0x05 Related Information

• scaffold-eth

• Web3-dApp-Camp

• https://guoyu.mirror.xyz/RD-xkpoxasAU7x5MIJmiCX4gll3Cs0pAd5iM258S1Ek

• learnblockchain community

国内用户请加微信：19726581

Authors: leeduckgo,msfew

The Talk about DAO section is a collection of NonceGeek's thoughts on the practice of DAO.

A Brief Analysis of the Relationship between Individuals and Organizations

In any kind of organization, the relationship between individual and organization is a very important topic that deserves deep consideration.

First of all, let's analyze the state of the organization.

Applying the concept of game theory, the game relationship between organization and individual can be divided into three kinds as follows.

• Zero-sum game: the organization creates very little new value, and the organization is only a "middleman" for the realization of individual labor value. At the same time, in order to maintain the organization itself, it also needs to take part of the value of individual labor as "commission".

• Negative sum game: The organization is going downhill. This is a very difficult time for both the organization and the individual. Many times the organization will even suppress the individuals, typically by withholding wages from employees.

• Positive game: The overall development is active.

It seems that, as individuals, we can choose the organization that is in a "positive-sum state" and be done with it.

But when you think about it, it doesn't seem so simple.

Let's consider two dimensions - the 'revenue dimension' and the 'growth dimension' - and we can get two tables.

+--------------------------------------------------+
|               Earnings Table                     |
+--------------------------------------------------+
|            |   Satisfaction  | Dissatisfaction   |
+--------------------------------------------------+
| Individual |                 |                   |
+--------------------------------------------------+
| Org        |                 |                   |
+--------------------------------------------------+

+--------------------------------------------------+
|                 Growth Table                     |
+--------------------------------------------------+
|            |   Satisfaction  | Dissatisfaction   |
+--------------------------------------------------+
| Individual |                 |                   |
+--------------------------------------------------+
| Org        |                 |                   |
+--------------------------------------------------+

Many companies in a "positive state" are able to achieve win-win on the revenue table, and both individuals and organizations are satisfied with their revenue.

However, the most difficult part of the entire narrative is the win-win of the growth table, which is often the most neglected.

Short-term consistency and long-term uncertainty between individual and organizational growth in organizations

In many cases, personal growth and organizational growth may be consistent in the short term, but they are uncertain in the long term. For example, a fresh graduate will join a suitable organization for high growth; at the same time, the fresh graduate will inject "fresh blood" into the organization.

However, in the long run, there may be differences in the direction and speed of growth between individuals and organizations.

Traditional organizations have cumbersome mechanisms for joining and exiting, so when such differences arise, they either have to live with it or go their separate ways.

However, the DAO format gives a solution to this paradox -- ideally, anyone in the organization has the right to afk (away from keyboard: temporarily leave) and btk (back to keyboard: come back) at any time.

In this case, even if the development of the individual is not in line with the development of the organization, then it only needs to afk, no need to report to anyone; when you want to develop with the organization, just btk back to participate in organizational activities.

In other words, the decision to join, work and quit in a traditional organization is in the hands of the organization, but a real DAO will return this right to the individual. Through this "power transfer", can we truly create a win-win strategy for individuals and organizations?

原文链接：https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4105763

论文作者：E. Glen Weyl, Puja Ohlhaver, Vitalik Buterin

翻译人：Leeduckgo@NonceGeek, Yaya@NonceGeek

可加我微信：197626581

2022 年, 5 月

道（DAO）者万物之奥。善人之宝，不善人之所保。

——老子, 62 章

摘要

如今的 Web3 以表达可转移的、金融化的资产为中心，而不是编码的社会信任关系。然而，许多核心的经济活动——如无抵押贷款和个人品牌的简历——都是建立在持久的、不可转移的关系之上的。在本文中，我们阐述了不可转移的灵魂绑定通证（SBTs），其代表“灵魂”的承诺、凭证和“灵魂”的附属物——它可以对实体经济的信任网络进行编码，以构建来源证明和声誉。更重要的是，SBTs 使其他具备远大愿景的应用成为可能，如社区钱包恢复、抗女巫攻击治理、权力下放机制和具有权利分解、权利共享的新市场。我们把这种更丰富、多元的生态系统称为“分散的社会”(DeSoc)——一种共同决定的社会性，灵魂和社区自下而上聚集在一起，作为彼此的新兴属性，在一定范围内共同创造多种网络商品和智能。

这种社会性的关键是可分解的产权和增强的治理机制——例如根据相关分数打折的二次方融资机制——奖励信任和合作，同时保护网络不被捕获、提取和支配。 借助这种增强的社交性，web3 可以避开当今的超金融化，转而支持更具变革性、多元化的未来，即跨社会距离的增加回报。

1 介绍

Web3 在不到十年的时间里打造了一个前所未有的灵活性和创造力的金融平行系统，震惊了世界。

密码学和经济学的原语，如公钥加密、智能合约、基于工作量的证明和基于权益的证明，已经创造了一个用于表现金融交易的，复杂和开放的生态系统。

然而，经济价值的交易是由人类及其关系产生的。因为 web3 缺乏原语来代表这种社会身份，所以它已经从根本上依赖于它旨在超越的非常集中的 web2 结构，复制了它们的局限性。

这些依赖关系的例子包括：

1.大多数 NFT 艺术家都依赖于像 OpenSea 和推特这样的集中式平台来致力于稀缺性和初始来源。

2.试图超越简单的硬币投票的 dao 通常依赖于 web2 基础设施，比如社交媒体的资料，来抵抗女巫攻击。

3.许多 web3 参与者依赖于由 Coinbase 或 Binance 等集中实体管理的托管钱包。分散的密钥管理系统对任何系统都是非用户友好的，是最复杂的系统。

此外，缺乏原生的 web3 身份使得今天的 DeFi 生态系统无法支持实体经济中无处不在的活动，例如抵押不足的借贷或简单的合同，例如公寓租赁。 在本文中，我们说明了即使是用灵魂绑定的通证表示社会身份的微小和渐进的步骤也可以克服这些限制，并使生态系统更接近于在原生 web3 环境中以人际关系为基础的再生市场。

更有希望的是，我们强调了具有丰富社会组合性的原生 web3 社会身份，如何在 web3 中围绕财富集中和金融治理脆弱性的更广泛的长期问题上取得巨大进展 攻击，同时刺激了寒武纪创新的政治、经济和社会应用的大爆炸。我们将这些用例和它们促成的更丰富的多元生态系统称为“分散社会”(DeSoc)。

更有希望的是，我们强调了具有丰富社会可组合性的原生 web3 社会身份如何在 web3 中围绕财富集中和治理易受金融攻击的脆弱性等更广泛的长期问题上取得巨大进展，同时刺激政治 、经济和社会应用的寒武纪式的创新大爆炸。 我们将这些用例和它们所支持的更丰富的多元化生态系统称为 “去中心化社会”（DeSoc）。

2 大纲

我们首先解释 DeSoc 的原语，围绕持有不可转让（最初公开）的灵魂绑定通证的账户（或钱包）。“灵魂绑定”通证（SBTs）代表承诺、凭证和附属物。这样的通证就像一份延长的简历，由其他钱包发行来证明这些社会关系。

然后，我们描述了跨社交栈的具有远大志向的应用程序的“阶梯”。这些原语可以赋予权力，包括：

● 建立来源

● 通过声誉解锁抵押贷款不足的贷款市场

● 支持去中心化的密钥管理

● 挫败和补偿协调的战略行为

● 衡量去中心化程度

● 创建了具有可分解的、共享的权利和权限的新市场

这一描述以 DeSoc 的愿景达到高潮——一种共同决定的社会性，灵魂和社区自下而上聚集在一起，作为彼此的涌现属性，在一系列社会尺度上共同创造多元的网络商品，包括多元的智能。

最后，我们回答了几个潜在的问题和反对意见，并与 web3 空间中熟悉的其他身份范式进行了比较，考虑到承认我们的愿景只是第一步，尽管如此也是可编程隐私和通信方面的进步。然后，我们考虑技术途径来引导我们想象的愿景。构建这些，我们更哲学地期待 DeSoc 的潜力，将 web3 重定向到一个更深刻、合法和变革性的路径。

3 灵魂

我们的关键原语是持有公开可见的、不可转让的（但可能是发行者可撤销的）通证的账户或钱包。我们将账户称为**“灵魂”，账户持有的标记称为“灵魂通证”(SBTs)**。尽管我们对隐私有着浓厚的兴趣，但我们最初假设是公开的，因为它在技术上更容易做概念验证，即使受到「愿意公开分享的通证」的这一人群子集的限制。 在本文的后面，我们为更丰富的用例引入了“可编程隐私”的概念。

想象一下这样一个世界，大多数参与者都有灵魂，它存储了与一系列的与 SBTs 相对应的附属品、成员资格和凭证。例如，一个人可能有一个灵魂，它存储了代表教育证书、就业历史、或他们的作品或艺术作品的 Hash的 SBTs。在它们最简单的形式下，这些 SBTs 可以被“自我认证”，类似于我们如何在简历中分享关于我们自己的信息。但是，当一个灵魂所持有的 SBTs 可以被其他对立的灵魂发行或证明时，这种机制的真正力量就出现了。这些对手灵魂可以是个人、公司或机构。例如，以太坊基金会可以是一个向参加开发者会议的灵魂发行 SBTs 的灵魂。一所大学可能是一个释放SBTs 的灵魂。体育场可能是向道奇队的长期球迷发放 SBTs 的灵魂。

请注意，灵魂不需要与合法名称相关联，也不需要任何协议级别的尝试来确保「每个人一个灵魂」。 灵魂可能是一个持久的化名，具有一系列无法轻易链接的 SBT。

我们也不假设灵魂在人类之间的不可转移性。 相反，我们试图说明这些属性如何在需要时自然地从设计本身中出现。

4 通往去中心化社会的阶梯

4.1 艺术与灵魂

灵魂是艺术家们把声誉押在作品上的一种自然方式。当发行一个可交易的 NFT 时，一个艺术家可以从他们的灵魂中发行 NFT。艺术家的灵魂携带的 SBTs 越多，买家就越容易确定该灵魂属于该艺 术家，因此也可以确保 NFT 的合法性。艺术家可以更进一步，发行一个存储在他们灵魂中的链接 SBT，证明 NFT 的“收藏”成员资格，并保证艺术家希望设置的任何稀缺性限制。因此，灵魂将创造一种可验证的、链上的方式，以确定一个物品的来源和稀缺性来建立声誉。

应用程序超越了艺术、服务、租赁，以及任何建立在稀缺性、声誉或真实性之上的市场。后者的一个例子是核实所谓的事实记录的真实性，如照片和视频。随着深度造假技术的进步，人类和算法 的直接检查将越来越无法检测出准确性。虽然 区块链包容性使我们能够追踪特定作品的制作时间，但 SBT 将使我们能够追踪 社会出处，为我们提供了丰富的社会背景来了解发布该作品的灵魂——他们的成员关系 、附属品、证书——以及他们与客体的社交距离。“Deep fakes” 可以很容易地识别出来，因为那些是来自时间和社会环境之外的文物，而可信的文物（如照片）将来自著名摄影师的认证。目前的技术将文化产品（如图片）去背景化，并使它们容易受到缺乏社会背景的未经检查的病毒式攻击，而 SBTs可以将这些对象重新背景化，并赋予灵魂利用社区中已经存在的信任关系，作为保护声誉的有意义的后盾。

4.2 灵魂借贷

直接建立在声誉之上的最大金融价值也许是信用和无抵押贷款。 目前，web3 生态系统无法复制简单形式的无抵押借贷，因为所有资产都是可转让和可销售的——因此只是抵押形式。

“传统” 金融生态系统支持多种形式的无抵押贷款，但依赖于集中的信用评分来衡量借款人的信用度，这些借款人没有动力分享有关其信用历史的信息。 但是这样的分数有很多 缺陷。 充其量，他们不透明地高估和低估与信用相关的因素，并对那些没有积累足够数据的人持有偏见——主要是少数族裔和穷人。 在最坏的情况下，他们可以启用黑镜中不透明的“社会信用”系统，从而设计社会结果并加强歧视。

一个 SBTs的生态系统可以开启一种抗审查的、自下而上的替代方案，以替代自上而下的商业和“社会”信贷系统。代表教育证书、工作历史和租赁合同的 SBTs可以作为信用相关历史的持续记录， 允许灵魂拥有有意义的声誉，以避免抵押品要求并获得贷款。贷款和信用额度可以被表示为不可转让但可撤销的 SBTs，所以它们被嵌套在灵魂的其他 SBTs 中——一种不可扣押的声誉抵押品——直到它们被偿还并随后被烧掉，或者更好的是，取而代之的是偿还证明。SBTs 提供了有用的安全属性：不可转让性防止转移或隐藏未偿贷款，而丰富的 SBTs 生态系统确保那些试图逃避还贷的借款人（也许通过创造一个新的灵魂）将缺乏能代表他们的声誉的 SBTs 。

使用 SBTs 计算公共债务的便利性将成为开源贷款市场。SBTs 和还款风险之间的新相关性将会出现，从而产生更好的预测贷款算法，从而减少集中的、不透明的信用评分基础设施的作用。更好的是，贷款很可能会发生在社会关系中。特别是，社交联系将成为社区贷款实践的基础，类似于穆罕默德·尤努斯和格林银行开创的做法，在那里，社交网络的成员同意支持彼此的债务。因为一个灵魂的 SBTs 归属代表了跨社会群体的成员身份，参与者可以很容易地发现其他的灵魂。他将是一个集团贷款项目的宝贵的共同参与者。商业贷款是一种“先贷后忘”直至还款的模式，而社区贷款可能会采取“先贷后助”的方式——将营运资本与人力资本相结合，从而获得更高的回报率。

4.3 不要失去你的灵魂

关键的 SBTs的不可转移性——比如一次性颁发的教育证书——提出了一个重要的问题：你如何不失去你的灵魂呢？今天的恢复方法，如多签恢复或记忆方法，在心智成本、易于处理和安全性方面做了权衡。「社交恢复」是一种新兴的选择，它依赖于一个人的信任关系。SBTs 允许一个类似的，但更广泛的范式：「社区恢复」。其中灵魂是其社会网络的交叉投票。

社交恢复是一个很好的安全起点，但在安全性和可用性方面存在一些缺陷。用户策划了一组 “监护人”，并让他们大多数人能够更换钱包里的钥匙。监护人可能是个人、机构或其他钱包的混合体。问题是，用户必须平衡监护人的数量、做好预防措施，即监护人来自离散的社会圈，以避免传统。此外，监护人可能会去世，人际关系恶化，或者人们只是失去联系，需要频繁和耗费注意力的更新。虽然社交恢复避免了单一的失败，但成功的恢复依赖于与大多数监护人的信任关系。

一个更强大的解决方案是将灵魂恢复与社区中灵魂的成员资格联系起来，利用最广泛的实时关系来确保安全。

回想一下，SBTs 代表了不同 社区的成员身份。其中一些社区——如雇主、俱乐部、大学或教堂——在本质上可能在链下更自然，而其他社区——如参与协议治理或 DAO——可能更应该在链上。在一个社区恢复模型中，恢复一个灵魂的私钥将需要一个来自灵魂社区的一个合格的大多数（随机子集）的成员才能同意。

就像社会恢复一样，我们假设灵魂可以访问安全的、链下通信通道，在这些通道中“认证”——通过对话、面对面的会面，或确定一个共享的秘密——这些都可以发生。这种通信信道将需要更大的带宽（技术上能够携带更丰富的“信息熵”），例如，链上机器人或 SBTs本身的计算。事实上，我们可以认为 SBTs从根本上来说，都是关于代表参与或访问这种真实的——即高带宽的通信通道。

要完成这项工作的精确细节还需要进行实验。例如，如何选择监护人以及需要多少监护人的同意，是进一步研究的关键安全参数。然而，有了如此丰富的信息基础，社区恢复在计算上应该是可能的，随着灵魂加入更多不同的社区并形成更有意义的关系，安全性也会增加。

社区恢复作为一种安全机制，涉及到了身份认同理论——这是被20 世纪之交的社会学家 Georg Simmel（社交王伦理论的提出人）在这个理论中，个性从社会群体的交集中出现，就像社会群体作为个体的交集出现一样。维护和恢复灵魂的加密财产需要灵魂网络的同意。通过在社交性中嵌入安全，一个灵魂总是可以通过社区恢复来再生他们的钥匙，这阻止了灵魂盗窃（或出售）：因为卖方需要证明出售恢复关系，任何试图出售一个灵魂的尝试都缺乏可信度。

4.4 灵魂投放

到目前为止，我们已经解释了灵魂如何能够代表个人，并在他们获得反映他们的关系、成员资格和证书的 SBTs 时反映他们的独特特征和团结性。 这种个性化有助于 Souls 建立声誉、确定出处、进入无抵押贷款市场并保护声誉和身份。 但反过来也是如此—— SBTs 还使社区能够在独特的灵魂交汇处召集。 到目前为止，web3 主要依靠通证销售或空投来召唤新社区，这几乎没有准确性或精确度。 通证通过算法免费提供给一组钱包的空投，主要属于现有通证持有者和钱包的某种组合——很容易被女巫攻击，鼓励策略行为和马太效应。 SBTs 提供了一种彻底的改进，我们称之为“灵魂投放”。

“灵魂投放”是基于灵魂内 SBTs 和其他通证计算的空投。 例如，想要在特定的一层网络协议中召集社区的 DAO，可以向持有最近 5 次会议出席 SBTs 中的 3 次的开发人员或其他反映出席情况的通证（如 POAP）的开发人员提供帮助。 协议还可以针对 SBTs 的组合以程序的方式进行加权通证空投。我们可以想象一个非营利组织，其任务是植树造林，将治理通证交给持有环境行动 SBTs、园艺 SBTs 和碳封存通证的灵魂——可能会向碳封存通证持有者投放更多通证。

灵魂投放还可以引入新的激励措施来鼓励社区参与。

丢弃的 SBT 可以设计为在一段时间内受到灵魂约束，但最终随着时间的推移“归属”为可转让的通证。 或者反过来也可行。 持有一段时间的可转让通证可以解锁 SBT 的权利，从而赋予协议进一步的治理权。 SBT 开辟了丰富的可能性空间来试验最大化社区参与和其他目标的机制，如权力下放，我们将在下面进一步讨论。

4.5 灵魂的黎明

分布式自治组织 (DAO) 是围绕一个共同目的聚集在一起的虚拟社区，通过公共区块链上的智能合约投票进行协调。 虽然 DAO 为跨距离和不同的全球社区的协调提供了巨大的潜力，但它们很容易受到女巫攻击，其中单个用户可以拥有多个钱包来累积投票权——或者在不太复杂的单通证一票式治理中，简单地囤积通证累积 51% 的投票权并剥夺其他 49% 的投票权。

DAOs 可以通过以下几种方式减轻女巫攻击，例如：

● 计算灵魂的 SBT 归属以区分独特灵魂和可能的机器人，并拒绝任何投票权给看似女巫的灵魂。

● 授予拥有更高声望的 SBT（如工作或教育证书、执照或证书）的灵魂更多的投票权。

● 发布专门的“人格证明” SBTs，这可以帮助其他 DAO 抵抗女巫攻击。

● 检查支持特定投票的灵魂持有的 SBT 之间的相关性，并对高度相关的选民应用较低的投票权重。

后一种相关性检查的想法特别有前途和新颖。 由分享相同 SBTs 的许多灵魂支持的投票更有可能是女巫攻击，而且——即使不是女巫攻击——这样的投票更有可能是一群具有相同的判断错误或具有相同偏见的人，因此应该合理地加权低于具有相同数量支持但来自更多样化的参与者基础的投票。

我们在二次融资的背景下更详细地探讨了后一种想法。在附录中，我们引入了一个新的原语，称为“相关性分数”。“这种相关性折扣的概念可以扩展到构建审慎的对话。例如，容易受到多数主义捕获的 DAOs 可以计算 SBTs，使最大限度地多样化的成员聚集在一起，并确保少数群体的声音被听到。

DAO 还可以依靠 SBT 来阻止各种形式的战略行为，例如“吸血鬼攻击”。 在此类攻击中，DAO（通常具有相关的具有经济价值的 DeFi 协议）通过复制他们的开源代码并随后用通证吸引用户的流动性来搭便车。 DAO 可以通过以下方式阻止搭便车者：DAO 可以阻止搭便车者，首先围绕灵魂投掷（可能授予 SBT）创建一个规范，仅针对提供流动性的可能的抗女巫灵魂，然后将灵魂投递给在吸血鬼攻击中转移流动性的灵魂。 同样的机制不适用于空投到钱包，因为持有人可以将流动性分散到许多钱包中以混淆他们的流动性轨迹。

DAO 还可以使用 SBTs 以编程方式响应其社区的领导和治理。 领导角色可以随着社区组成的变化而动态变化——正如 SBT 在成员灵魂中的分布变化中所反映的那样。 根据 DAO 内多个社区的交叉性和覆盖范围，可以将一部分成员提升为潜在的主管角色。 重视社区凝聚力的协议可以使用 SBT 将交叉灵魂保持在中心。 或者，DAO 可能会选择比其他更提升某些特征组合的治理，例如邮政编码之间的多样性或特殊爱好 DAO 子集的参与。

4.6 通过多元主义确保去中心化

在分析现实世界的生态系统时，最好是衡量生态系统实际上有多去中心化。生态系统在多大程

度上是真正去中心化的，去中心化在多大程度上是“假的”，而生态系统实际上是由一个或一小部分协调实

体所主导的？

两个流行的去中心化指标被称为「Nakamoto 相关性」，由 Balaji Srinivasan 提出，他测量了合并多少不同的实体来收集 51%的一些资源，以及 Herfindahl-Hirschman 用于反垄断目的衡量市场集中度的指数，通过将市场参与者的市场份额的平方相来计算。。然而，这些方法留下了一些关键的问题，即什么是需要衡量的正确资源，如何处理部分协调，以及什么是构成“独特实体”的灰色地带。

例如，名义上独立的退休股东可能有许多共同的大股东，有彼此是朋友的董事，或受到同一个政府的监管。在通证协议的背景下，通过查看链上的钱包来衡量通证持有的分散化是非常不准确的，因为许多人有多个钱包，而一些钱包（如交易所钱包）代表了很多人。此外，即使地址可以追溯到独特的个体，这些个体也可能是与社会相关的群体，容易发生偶然的协调（在最好的情况下）或有意的勾结（在最坏的情况下）。衡量权力下放的更好方法是捕捉社会依赖、弱关联和强团结。

矿工和矿业池运营商总共占比特币哈希功率的 90%，他们一起坐在一个会议小组上。

SBTs 支持一种不同的方式来衡量 DAO、协议或网络中的去中心化（或多元化）水平。

• 作为第一步，协议可以限制通证投票到合理的女巫攻击抵抗（或复 SBT）的灵魂；

• 作为第二步，协议可以检查不同灵魂持有的 SBTs 与灵魂的折扣投票之间的相关性（将它们合并为仅部分分离），如果它们共享大量 SBTs（我们在附录 A 的二次融资背景下更详细地探讨了后一个想法，我们在其中引入了一个新的原语，称为「相关分数」）；

• 作为第三步，为了缩小并了解整个网络的去中心化程度，可以测量 Souls 持有的 SBT 在网络堆栈的不同层之间和跨层之间的相关性——测量投票、通证所有权、治理相关的相关性通信，甚至控制计算资源。

SBT 使我们能够开始衡量当今很难衡量的互操作和分层生态系统的去中心化程度。 关于哪些公式最能捕捉我们想要测量的内容并且最不容易受到操纵，仍然存在一个很大的悬而未决的问题。 还有很多关于如何检查 SBT 的关系的问题——对某些 SBT 的权重比其他的更高，对嵌套的 SBT 进行折扣，或者还考虑到 Souls 中可转让通证的组成。 然而，随着 Souls 和 SBT 的丰富生态系统，大量数据可用于进行这些计算并朝着有意义的去中心化方向发展。

4.7 多元属性

DAO 通常在虚拟世界和物理世界中拥有或围绕拥有资产进行组织。到目前为止，web3 的范围主要限于一小部分财产，其权利捆绑完全可以转让：通证、NFT、艺术品、第一版或像美国宪法这样的稀有手稿。但是，对可转让性的强调对 Web3不利，使其无法代表和支持当今一些最简单且无处不在的财产合同，例如公寓租赁。财产权在罗马法律传统中被定义为使用（“usus”）、消费或破坏（“abusus”）和获取利润（“fructus”）的权利。很少有所有这些权利共同归属于同一所有者。例如，公寓租赁授予出租人有限的使用权（“usus”），但不能无限制地破坏公寓（“abusus”）、将其出售（“fructus”），甚至转让使用（转租） 。不动产（土地）的权利通常受到一系列私人使用限制、公共使用权授予、销售权限制，甚至征用权购买权的限制。他们通常还背负着将一些金融价值转移给贷方的抵押贷款。

财产创新的未来不太可能建立在迄今为止想象的 web3 完全可转让的私有财产之上。 相反，创新将取决于分解财产权以匹配现有财产制度特征的能力，并编写更丰富的细节。 公司和其他组织形式的演变正是为了以更具创造性的方式重新配置产权——例如，授予员工使用专有设施（“usus”）的权限，但保留经理更改或损坏资产的权利（“abusus”），同时支付股东最大的财务利润（“fructus”）。 SBT 具有表现和扩散实体和虚拟资产的此类细微产权的灵活性，同时鼓励新的实验。 这里是一些用例：

• 允许访问私人或公共控制的资源（例如，房屋、汽车、博物馆、公园和虚拟等价物）。 可转让的 NFT 未能很好地捕捉到这个用例，因为访问权限通常是有条件的且不可转让的：如果我相信你会进入我的后院并将其用作娱乐空间，这并不意味着我授予你会将这个权益给予他人的子许可。

• 通过SBTs 向研究人员授予数据访问权限的数据联合体，同时赋予成员授予访问权限的权利（可能通过二次方投票）并就研究产生的发现和知识产权的经济权利进行谈判。 我们将在第 4 节“多元意义构建”中进一步探讨这一点。

• 使用当地货币进行实验，其规则使居住在特定地区或属于特定社区的灵魂更有价值地持有和消费它们。

• 参与实验，其中 SBT 为较少情境化的灵魂（例如移民、青少年）在新颖和更广泛的网络中获得影响力创造了持续的基础。 这样的灵魂将从有限的 SBTs 开始，将他们与家人或当地社区集中在一起。 随着他们的联盟逐渐多样化，他们将获得更广泛的 SBTs，以实例化投票权以影响更广泛的网络——本着 Danielle Allen 的多元政治理念的精神——这一过程目前由年龄和居住地限制来调节。

• 市场设计实验，例如 Harberger 税收和 SALSA（在拍卖中出售的自我评估许可证），其中资产持有人发布自我评估价格，任何其他人都可以从他们那里购买资产，并且必须定期按比例缴纳税款对自评价格保持控制。 SBT 可用于创建更细微的 SALSA 版本——例如，社区批准参与权，以尽量减少来自社区内部或外部的策略行为。

• 二次投票等民主机制设计的实验。 代表社区成员的 SBTs 持有者可以对激励和税率等参数进行二次投票。 归根结底，“市场”和“政治”不是独立的设计空间。 SBTs 可以成为技术堆栈的主要部分，可以探索两个类别之间的整个空间。 通过二次方融资提供公共商品是另一个这样的交叉点。

当然，还有一些反乌托邦场景需要考虑。 移民系统可以通过迁移 SBTs 获得许可。 监管捕获可以编入嵌套的社区通证中，其中房主拥有不成比例的投票权并阻碍住房建设。 SBTs 可以使红线自动化。 正如我们在下面进一步讨论的那样，应该在当前不透明的自上而下的权限和歧视的背景下考虑这些场景。 SBTs 使歧视更加透明，因此可能具有争议性。

4.8 从私人商品和公共商品到多元网络商品

更一般地说，SBTs 可以让我们有效地代表和管理介于完全私有和完全公共之间的任何资产和商品。 实际上，几乎所有东西都在范围内：即使是个人消费的商品也有积极的溢出效应，例如使消费者能够更好地为他们的家庭或社区做出贡献，甚至全球最容易获得的公共商品（例如气候）也不可避免地更有用 有些人比其他人好（例如塞舌尔对比于西伯利亚）。 同样，人类的动机很少是完全自私或完全利他的。 有许多预先存在的合作模式，某些社区比其他社区更多。

然而，今天的机制设计假设原子化的、自私的代理人没有预先存在的合作，这往往使机制容易受到无意的过度协调的影响，最坏的情况是故意勾结。因此，即使是最好的公共融资模式，包括二次方融资 (QF)，也无法进行扩展。 QF 通过为少数人的集中行动提供递减的奖励来鼓励协调，但为多数人的集体行动提供增加的奖励；例如，10 人平均贡献的 1 美元与 99 美元相匹配，总共产生 100 美元，而一个人贡献的 10 美元则没有匹配。在数学上，这是通过匹配与个人捐款平方根之和的平方成正比的资金来实现的（我们在附录中进一步详细说明）。但是，即使大型团体（比如大多数 K 国公民）之间的合作很弱（比如向一项事业捐款 1 美元）也会主导系统并吸收所有匹配的资金，因为优质 QF 会增加独特贡献者的数量。像现在这样，QF 不会忽视可能淹没 QF 轮次的相关特殊利益之间的协调，而是奖励它。

但是，与其将预先存在的合作视为我们应该“改写”的错误，关键是承认它反映了我们应该利用和补偿的部分合作。 毕竟，我们从事的是鼓励合作的业务。 诀窍是让二次机制与预先存在的合作网络一起工作，纠正它们的偏见和过度协调的倾向。 SBTs 提供了一种自然的方式，它允许我们倾斜天平以支持跨越差异的合作。 正如诺贝尔奖获得者 Elinor Ostrom 著名地强调的那样，问题不在于协调公共产品本身，而在于帮助由不完全合作但具有社会联系的个人组成的社区克服他们的社会差异，在更广泛的网络中进行大规模协调。

如果 SBTs 代表反映灵魂偏向性的社区成员资格，那么支持跨差异合作仅仅意味着将合作奖励折扣给类似关联或相关的灵魂——由他们共享的 SBT 衡量的相似性。 假设是，不同关联的更好的共识信号跨更广泛的网络的多种商品，而相似关联的更可能的共识信号是服务于更窄利益的过度协调（或共谋）商品。

通过揭示 Souls 中的共享成员资格，SBTs 允许我们打折预先存在的合作，并二次扩大在新兴网络中广泛赋予利益的多元商品——由最多样化的成员同意——而不是更狭窄的商品被特殊利益集团无意的过度协调（或故意勾结）。 相关折扣“最佳”的精确公式取决于模型细节，尚未研究，但我们在附录中提供了第一次实验以供进一步研究。

5 多元感官

在数字世界中日益突出的多元网络商品的一个例子是利用用户数据建立的预测性模型。艺术智能（AI）和预测市场都试图根据主要来自人的数据来预测未来的事件。事件，主要是基于从人那里获得的数据。但这两种模式都有不同的局限性，而且几乎是相反的。恰恰相反。人工智能的主导模式避开了激励机制，而是囤积（公共或私人监控的）数据资料，并对其进行合成监视的）数据源，并通过专有的大规模非线性模型将其合成为预测结果--利用默认的 web2 对 "usus "的垄断，而不对数据劳动者提供任何 "fructus"。预测市场采取相反的方法，人们对结果进行投注，希望获得经济收益。完全依赖金融投机的经济激励（"果实"），而不去综合投注者的信念赌徒的信念来产生可组合的模型。同时，这两种范式得出的结论都是被描述为 "客观 "真理的结论；而人工智能模型被描述为 "普遍的 "或 "一般的而人工智能模型则被描述为 "普遍 "或 "智能"，预测市场则被描述为将市场参与者的所有信念归纳为一个单一的数字: 均衡价格。

一个更有成效的范式是避开这些极端，而吸取两者的优点, 同时弥补它们的弱点并丰富它们的广度。我们建议深思熟虑地将非线性人工智能模型的复杂性与预测市场的市场激励机制相结合，将被动的数据劳动者变成主动的数据创造者。有了这种扎根于数据创造者的社会性的丰富信息我们说明了DeSoc如何释放出比任何一种方法都更强大的多元网络（ed）智能。

5.1 预测市场到预测的多元性

预测市场的目的是根据那些愿意赌钱的人的财富和风险偏好来聚集信念-有钱能使鬼推磨。但是，这种 "生存测试 "并不是一种理想的信仰聚集方式。一个零和游戏，一个交易者的收益就是另一个交易者的损失，它假定了一种普遍的预测能力，与 "聪明人 "而不是 "傻瓜 "搏斗。虽然财富可能是某些形式的能力和专业知识的代表，但考虑到其他形式的相对专业知识的预测可能更可靠。在某一特定领域赌输了的参与者，在另一领域可能有更准确的信念。但是，预测市场有一个不幸的结果，那就是激发那些容易赌博的人的信念，这使那些赢得赌注的人变得富有，使其余的人变得贫穷，并使那些不愿承担风险的人不愿意普遍参与。

有更好的方法来激发人们的信念。研究表明，虽然预测市场的表现通常优于简单的投票，但它们并不优于复杂的团队预测投票，在这种情况下，人们有激励措施来分享和讨论信息。在团队商议模式下，成员可以根据过去的表现和同行的评价等因素进行加权，团队参与半结构化的讨论，以汇集不能简单地封装在买卖合同中的信息。这样的团队商议模型可以用二次方规则进一步改进，以从所有参与者那里获得准确的概率估计（与预测市场相比，预测市场只获得关于当前价格平衡的上下观点）。已经证明，人们有动力购买的合同数量反映了他们的主观概率。买的合同数量反映了他们的主观概率评估。这样的市场也能更平等地分配参与的收益。奖励准确的人而不使其他人破产，从而使每个人都能在未来的回合中成为参与者。奖励准确率而不使其他人破产，从而使每个人都成为未来几轮的参与者。

SBTs可以开启一类新的丰富的模型，并在预测能力和相对专业知识方面进行实验。预测市场给出了一个数字--合同的价格，而二次投票给出了每个参与者对某一事件的概率的确切信念。SBTs能够在社会背景下对这些信念进行进一步的计算，包括一个人的教育证书、会员资格和一般的社会性。参与者开发更好的加权（或非线性综合）预测模型，很可能在新的、不可预见的交叉点上浮现出专家预测者。因此，即使民意调查没有很好地汇总信仰，也可以对民意调查进行追溯研究，以发现 "更正确 "的参与者的特征，并在未来的民意调查中召集更有针对性的 "专家"，也许是在一个审议小组的背景下。这些机制与我们在本文中倡导的机制密切相关。同样，由相关分数折算的二次方机制可以将协调不佳的自上而下的公共产品转化为强大的。同样，它们也可以将基于零和预测市场的治理系统转变为正和多元的感知机制，因为零和预测市场激励参与者隐藏他们的信息（例如Futarchy）。决策，从而鼓励新的和更好的信息的揭示和综合。

5.2 人工智能到多元智能

大规模的非线性 "神经网络 "模型（如BERT和GPT-3）也可以通过SBT进行转换。由SBTs进行改造。这类模型可以收集大量的公共或私人监控的数据，以产生丰富的模型和预测。丰富的模型和预测，如基于自然语言提示的代码。大多数被监控的数据创建者没有意识到他们在创建这些模型中的作用，没有保留任何剩余权利，并被视为 "附带的"，而不是关键的参与者。此外，数据收集使模型脱离了它们的社会背景，这掩盖了它们的偏见和局限性，并使它们被视为 "偶然的 "而不是关键的参与者。这掩盖了它们的偏见和局限性，削弱了我们对它们进行补偿的能力。这些紧张关系已经随着对数据可用性的要求越来越高，这些矛盾也日益凸显出来，"数据集的数据表 "等新举措记录了数据出处。数据集的数据表 "等新举措来记录数据出处，以及机器学习的隐私保护方法，这些矛盾日益凸显。这样的这些方法需要给那些产生数据的人以有意义的经济和管理利益，并激励他们合作产生数据。激励他们合作产生比他们单独建立的更强大的模型。

SBT提供了一种自然的方式，为富含来源的数据制定经济激励措施，同时赋予数据创建者对其数据的剩余治理权。特别是，SBTs允许对个人和社区的数据（和数据质量）基于他们的特点进行仔细和有针对性的激励。同时，模型制作者可以跟踪所收集的数据的特征和他们的社会背景--这是对他们的影响。同时，模型制作者可以跟踪SBT所反映的所收集的数据及其社会背景，并找到能够消除偏见和补偿局限的贡献者的限制。SBTs也可以为数据创造者提供定制的管理权，允许他们组成合作组织，汇集数据并协商使用。数据创造者的这种自下而上的可编程性使得未来的多元智能成为可能。未来的多元智能，模型制作者可以通过竞争来协商使用相同的数据来建立不同的模型。因此，我们摆脱了一个独立的单一的 "艺术智能 "的模式摆脱了脱离人类起源，囤积无出处的监控数据的模式，而变成了寒武纪时期的爆炸性增长，即合作构建的多元智能体。取而代之的是合作构建的多元智能，这些智能植根于社会渊源，并由灵魂管理。

随着时间的推移，正如SBT使灵魂个体化一样，它们也会使模型个体化--将数据出处、管理和经济权利直接嵌入模型的代码中。因此，多元智能体像人类--建立一个嵌入人类社会性的灵魂。或者取决于你如何看待它，人类随着时间的推移，嵌入在多元智能体中进化。每个人都有一个独特的灵魂，与其他灵魂互补和合作。在这一点上，我们看到了预测市场和人工智能范式的融合，走向多元的感知，结合广泛分布的激励措施和对社会环境的仔细跟踪，创造出一种多种多样的模式，将两种方法的优点结合起来，形成一个比任何一种方法都更强大的技术范式，比任何一种都更强大。

5.3 可编程的多元隐私

多元智能体提出了关于数据隐私的重要问题。毕竟，要建立这样强大的需要从大型数据集（如健康数据）中汇集不同个体的数据，或捕获非人际但共享的数据（如社交图）。不是人与人之间的，而是共享的（例如，社交图）。"自我主权身份 "的倡导者倾向于把数据作为私有财产：关于这个互动的数据是我的，所以我应该能够选择何时以及向谁披露这些数据。然而，甚至比起实体经济，数据经济在简单的私有财产方面也很难理解。简单的私有财产方面的理解。在简单的双向关系中，比如说非法航空，披露信息的权利信息通常是对称的，通常需要相互许可和同意。正如学者Helen Nissenbaum强调，人们关注的不是 "隐私 "本身，而是在分享信息时缺乏对背景的完整性。信息的完整性。剑桥分析公司的丑闻在很大程度上是关于人们透露他们的社交图谱和朋友的信息的属性，而不涉及他们自己。剑桥分析公司的丑闻主要是关于人们在未经他们同意的情况下透露他们的社交图谱和朋友的信息。

与其说隐私是可转让的财产权利，不如说更有希望的方法是将隐私视为将隐私视为一个可编程的、松散耦合的权利捆绑，允许访问、改变或从信息中获利。信息的权利。在这种模式下，每一个SBT--例如代表一个证书或访问一个数据存储的SBT--最好也有一个隐含的可编程的产权，指定对构成SBT的基础信息的访问。构成SBT的基础信息：持有者、他们之间的协议、共享财产（如数据）。财产（如数据），以及对第三方的义务。例如，一些发行者会选择将SBTs完全公开。一些SBTs，如护照或健康记录，将是自我主权意义上的隐私，携带SBT的灵魂有单边披露的权利。其他的，如反映数据合作组织成员资格的SBTs，将有多重签名或更复杂的社区投票权限。在这种情况下，所有或大多数的SBT持有者必须同意披露。

虽然目前存在一些技术问题（SBTs能否以这种方式编程？围绕激励相容性的重要问题（在第7节中进一步探讨）--但我们仍然认为可编程的多元隐私值得进一步研究，并且与其他模式相比具有关键优势。

根据我们的方法，SBT有可能使隐私成为一种可编程的、可组合的权利，即可以映射到我们今天拥有的一套复杂的期望和协议上。此外，这种可编程性可以帮助我们重新想象新的众生相。隐私--作为一种允许获取信息的权利--可以与 "usus"、"abusus "和 "fructus "组成，以创造一个细微差别的获取权的组合，这有无限多的方式。例如，SBTs可以允许对数据存储的计算--也许是由多个灵魂拥有和管理的--使用一种特殊的隐私保护的技术。一些SBTs甚至可以允许对数据的访问，在这种情况下，某些计算可以进行，但是可以进行计算，但其结果不能向第三方证明。一个简单的例子是投票。投票机制需要统计每个人的票数，但票数不应证明给其他人，以防止买票。

通信也许是共享数据的最典型形式。然而，今天的通信渠道既缺乏用户控制和管理（"usus "和 "abusus"），同时又将用户的注意力（"fructus"）拍卖给出价最高的人，即使是机器人。SBTs有潜力管理更健康的注意力经济 "的形式，使灵魂有能力从他们的社交图谱之外的可能的机器人那里获得垃圾信息。他们的社交图谱，同时提升来自真实社区和所需交叉点的沟通。听众可以更清楚地知道他们在听谁的声音，并能更好地将功劳分配给那些能激发洞察力的作品。激发洞察力。与其优化最大限度的参与，这样的经济可以优化为正和合作和有价值的共同创造。这样的沟通渠道对安全也很重要。如上所述，"高带宽 "的沟通渠道对建立社区恢复的安全基础至关重要。

6 去中心化社会

Web3希望能广泛地改造社会，而不仅仅是金融系统。然而，今天的社会结构--家庭、教会、团队、公司、公民社会、名人、民主--在虚拟世界（通常称为 "元空间"）中是毫无意义的。如果没有代表人类灵魂和更广泛的关系的基元，虚拟世界（通常称为 "元宇宙"）就没有意义。如果web3摒弃了持久的身份，他们的信任和合作模式，以及他们的可组合的权利和权限，我们就会看到，分别是辛比尔攻击、串通和一个有限的完全可转让的私有财产的经济领域--所有这些都是超金融化的趋势。

为了避开超级金融化，但又能释放出指数级的增长，我们建议增强和桥接我们在虚拟和物理现实中的社会性，使灵魂和社区有能力编码丰富的社会和经济关系。但是，仅仅建立在信任和合作上是不够的。纠正纠正信任网络中的偏见和过度协调（或勾结）的倾向，对于鼓励比以前更复杂、更多样化的社会关系至关重要。我们将此称为"去中心化社会（DeSoc）"：一种共同决定的社会性，其中灵魂和社区的召集自下而上，作为彼此的新兴属性，在不同的规模上产生多元的网络商品。

我们强调多元网络商品是DESOC的一个特点，因为网络是经济增长最强大的引擎，但也最容易被私人行为者（如web2）以及其他一些机构（如美国国家航空航天局）破坏。经济增长的引擎，但却最容易被私人行为者（如web2）和强大的政府以神秘主义的方式捕获。大多数显著的经济增长来自于越来越多的网络回报，每增加一个单位的投入就会产生越来越多的产出。简单的物理网络的例子包括道路、电网、城市和其他形式的基础设施。劳动力和其他资本投入建立的网络。强大的数字网络的例子包括市场。预测模型和以数据为基础的多元智能。在这两种情况下，网络经济学与新古典主义经济学不同，后者讲究收益递减--每增加一个单位的投入，产出就会递减，而私有财产会产生最有效的结果。私有财产，应用于收益递增的情况下，会产生相反的效果--通过榨取租金来抑制网络增长。两个城市之间的公路可以从贸易收益中释放出越来越多的回报。但同样的道路，如果业主选择榨取的租金达到了交易价值，那么私人拥有的道路就会扼杀增长和价值。网络的公共所有权也有其自身的危险性，容易受到监管部门的控制或资金不足的影响。

如果不把网络当作纯粹的公共产品或纯粹的私人产品，而是当作部分和多元的共享产品，那么，收益递增的网络是最有效的。纯粹的私人物品，而是作为部分和多元的共享物品时，收益递增的网络是最有效的。DeSoc提供了一个社会基底对权利进行拆分和重组--使用权（"usus"）、消费权或破坏权（"abusus"）和的权利（"fructus"），并在这些权利之间建立起有效的治理机制，以增强信任和合作，同时检查串通和捕获。我们在本文中已经探讨了几种机制我们在本文中探讨了几种机制，如基于社区的SALSA和由相关分数折算的四次方资金（和投票）。这种部分和多元所有权的第三种方式避免了私人寻租的卡律布迪斯（Charybdis）和公共监管的希拉（Scylla）。

在许多方面，今天的DeFi是一个递减回报的私有财产范式，并将其追溯到增加回报的网络。建立在不信任的前提下，DeFi本质上被限制在完全可转让的私有财产（如可转让的通证）领域。完全可转让的私有财产（如可转让的通证），主要是将 "usus"、"abusus "和"fructus"。在最好的情况下，DeFi有可能通过榨取租金来扼制网络的发展，在最坏的情况下，有可能迎来的是由 "鲸鱼 "主导的乌托邦式的监控垄断，这些 "鲸鱼 "会收集并囤积数据。鲸鱼 "主宰的神秘主义监控垄断，他们在收集和囤积数据的过程中进行竞争--就像web2.com一样。

DeSoc将DeFi对网络价值的控制和猜测的竞赛转变为自下而上的协调来建立、参与和管理它们。至少，DeSoc的社会底层可以使DeFi具有抗虫性（实现社区治理）、抗吸血鬼性（将积极的外部性内部化，以建立一个开源的网络）和抗串通性（维护社区治理）。构建一个开源的网络），以及防串通（保持网络的去中心化）。随着DeSoc的结构性修正，DeFi可以支持和扩大复数网络，赋予其利益而不是进一步巩固被狭隘利益所控制的网络。

然而，DeSoc的最大优势在于其网络的可组合性。持续增长的回报和网络的增长并不只是为了避免榨取租金的危险，也是为了鼓励嵌套网络的扩散和交叉。一条公路可能在两个城市之间形成一个网络。但是，从更广泛的合作中切削减了更广泛的合作，两个合作的城市最终会遇到收益递减的上限，因为拥挤（道路和住房）或枯竭（达到他们所能服务的人群的极限）。只有通过技术创新和越来越广泛的合作，即使是比较松散的邻近网络的合作，以获得不断增长的回报的新来源，价值才能继续成倍增长。一些合作将是有形的，逐步扩大跨空间的物理贸易。但更多的的连接将是信息和数字的。随着时间的推移，我们将看到物理和数字网络之间新的合作矩阵。依赖于并扩展它们所建立的社会互连。这种交叉的、部分嵌套的、跨越数字和物理世界的不断增长的网络合作，正是DeSoc所促成的。

通过组成网络和协调，DeSoc出现在政治和市场的交汇点上。市场的交汇点--用社会性增强两者。DeSoc增强了JCR Licklider的愿景--他是创建互联网的ARPANET的创始人。他是ARPANET的创始人，该网络创造了互联网--"人机共生 "的 "星系间计算机网络"。在一个 "星系间计算机网络 "中的 "人机共生"，在信任的基础上极大地增加了社会活力。与其说DeFi是建立在无信任的前提下，DeSoc对支撑当今实体经济的信任网络进行编码，并使我们能够利用它们能够产生对捕获、提取或支配有弹性的多元网络商品。有了这种有了这种增强的社会性，web3可以放弃短期的超级金融化，而选择一个无限制的、跨越社会距离的回报的未来。

6.1 灵魂可以上天堂......也可以下地狱

虽然我们有选择地强调了我们认为有希望的DaSoc所释放的潜力，但重要的是要记住，几乎任何具有这种变革潜力的技术都会有类似的特点。重要的是要记住，几乎任何具有这种变革潜力的技术都会有类似的破坏性变革潜力。破坏性改造的潜力：火力燃烧，车轮碾压，电视洗脑，汽车污染，信用卡困住债务，诸如此类。在这里，同样的SBTs可以被用来弥补在这里，同样的SBTs可以用来补偿群体内的动力并实现跨地域的合作，也可以用来自动对不受欢迎的社会群体进行红线划分，甚至可以用来对不受欢迎的社会群体进行红线划分。不受欢迎的社会群体，甚至将他们作为网络或物理攻击的目标，执行限制性的移民政策，或提供掠夺性贷款。在当前的web3生态系统中，许多这样的可能性并不突出，因为在目前的基础上，它们并不是有意义的概念。启用DeSoc的优势也会造成这些伤害。正如拥有心脏的坏处是心脏可能会被打碎一样，拥有灵魂的坏处是它可能会下地狱，而拥有社会的坏处是社会经常被仇恨、偏见、暴力和恐惧所驱动。人性是一个伟大的、常常是悲剧性的实验。

当我们思考DeSoc可能的乌托邦时，我们也应该把这些可能性放在其他技术性乌托邦的背景下。在其他技术促成的乌托邦中。Web2是不透明的专制监视和社会控制的架构。虽然web2经常依靠自上而下的艺术官僚机构来授予身份（"驾照"），但它是一个不透明的结构。而DeSoc依靠的是横向（"点对点"）的社会证明。而DeSoc赋予了灵魂对他们自己的关系进行编码并共同创造多元财产，而web2则以社会联系为中介或用不透明的算法将其货币化，这些算法可能会使人分化、分裂和误导。DeSoc避开了自上而下、不透明的社会信用体系。Web2构成了它们的基础。DeSoc将灵魂视为代理人，而web2将灵魂视为对象

在没有任何身份基础的情况下，DeFi的社会控制风险较小，至少在短期内是如此。但DeFi有它自己的乌托邦。虽然DeFi克服了明确的集中化形式--即特定的行为者在一个系统中拥有超水平的正式权力--但它没有内置的方法来克服通过串通和市场力量的隐性集权。垄断并不总是像过去的 "标准油 "那样出现。勾结甚至可以发生在生态系统的更高和更远的地方，在一个生态系统的更高层次上。我们今天看到了这一点，一类机构资产管理公司的崛起（例如，anguard、BlackRock、State Street、Fidelity等）的崛起，他们是所有大型银行的最大股东。航空公司、汽车公司和其他主要行业的最大股东。由于这类资产管理公司持有一个行业内所有对手的股份（比如持有每家主要航空公司的股份），他们的动机是使他们所持有的公司看起来像一个竞争性的行业，但行动起来却像一个垄断者，使整个行业的利润最大化并以消费者和公众的利益为代价来巩固自己的地位。

在DeFi中，同样的 "鲸鱼 "和风险投资人在堆栈的每一层都积累了更大的股份，并且在堆栈内的竞争者之间也是如此。在一个堆栈内的竞争者之间积累了更大的份额，也许在通证管理中投票，或将其委托给同一级别的委托人，他们在整个网络中也有类似的相关性。如果没有任何社会基质来抵制强行功能分散化和相关折扣，我们也应该期待看到更多由鲸鱼资助的垄断，因为垄断者日益成为最大的可用投资资本。随着 "金钱阶层 "和用户的分歧，我们应该看到（并且已经看到）越来越多的越来越多的激励错位和榨取租金。如果出现处理私人数据的DeFi应用，我们很可能会看到类似的动态，比如应用鼓励多个 "拥有 "数据的人之间进行竞标，这些人 "拥有 "实际上是人际关系的数据（例如他们的社交图），以建立单一的私有AI来与人类竞争，避免未来出现增强人类的多元人工智能的竞争。

因此，DeSoc不需要完美地通过可接受的非乌托邦的测试；要成为一个值得探索的范式，它只需要比现有的替代品更好。要成为值得探索的范式，它只需要比现有的替代方案更好。虽然DeSoc有可能出现需要防范的乌托邦情景，但web2和现有的DeFi正在陷入不可避免的乌托邦模式，将权力集中在决定社会结果或拥有大部分权力的精英阶层。不可避免的是，权力集中在决定社会结果或拥有大部分财富的精英阶层。web2的方向是决定性的专制，加速了自上而下的监视和行为操纵的能力。监视和行为操纵的能力。今天的DeFi的方向是名义上的无政府资本主义，但是已经陷入网络效应和垄断的压力中，其中期路径有可能变成同样方式的专制。

与此相反，DeSoc是随机的社会多元主义--由个人和社区组成的网络，作为彼此的突发属性，共同决定自己的未来。纵观web2，其可以把DESOC的发展比喻为民众参与式政府从几个世纪的君主制中崛起。君主制，参与式政府并不是不可避免地产生了民主；它也导致了共产主义和法西斯主义的兴起。同样地，SBTs并没有使数字基础设施本质上变得民主，而是民主相容性取决于灵魂和社区共同决定的东西。开放这种可能性空间是对web2的独裁主义和DeFi的无政府资本主义的明显改进。

7 实施挑战

隐私对 DeSoc 来说是一个关键挑战。 一方面，太多的公共 SBTs 可能会泄露太多关于灵魂的信息，使他们容易受到社会控制。 另一方面，过多的纯私有 SBTs 也可能导致通过私有沟通渠道避开治理和社会协调的相关性折扣——这提出了重要的激励相容性问题。 与隐私问题密切相关的是欺骗问题：灵魂可能会歪曲他们的社会团结，同时通过私人或辅助渠道进行协调。 我们不能渴望知道所有的可能性和答案，而是在这里探索挑战的本质，并为未来的研究勾勒出一些有希望的路径。

7.1 私有灵魂

基于区块链的系统默认是公开的。 记录在链上的任何关系不仅对参与者，而且对全世界的任何人都是立即可见的。 使用多个假名可以保留一些隐私：家庭灵魂、医疗灵魂、专业灵魂、政治灵魂，每个都携带不同的 SBT。 但是如果用户天真地来操作，很容易将这些灵魂相互关联起来。 这种缺乏隐私的后果是严重的。 事实上，如果没有采取明确的措施来保护隐私，简单地将所有 SBTs 上链的“幼稚”愿景很可能会使许多应用程序公开太多信息。

为了应对过度的公开化，有许多具有不同技术复杂性和功能级别的解决方案。 最简单的方法是 SBT 可以在链下存储数据，只留下链上数据的哈希值。

如何存储链下数据的选择由个人决定； 可能的解决方案包括

（i）他们自己的设备；

（ii）他们信任的云服务；

或（iii）去中心化网络，例如星际文件系统（IPFS）。

将数据存储在链下让我们继续拥有向存储 SBTs 数据的智能合约写入的权限，但同时拥有读取该数据的单独权限。 Bob 可以选择仅在他愿意时透露他的任何 SBTs（或他们允许的数据存储）的内容。 这已经让我们走得很远，并且具有提高技术可扩展性的进一步好处，因为大多数数据只需要由极少数各方处理。 但要完全实现多元隐私等属性，以及更细粒度的披露形式，我们还需要更进一步。 幸运的是，许多加密技术让我们能够做到这一点。

一个强大的工具能够以新的方式部分揭示数据，它是密码学的一个分支，称为“零知识证明”。 虽然如今零知识证明最常用于保护隐私的资产转移，但它们也可以让人们证明任意陈述，而无需透露陈述本身之外的任何更多信息。 例如，在一个政府文件和其他证明可以通过密码证明的世界中，有人可以证明这样的陈述：“我是加拿大公民，年满 18 岁，拥有大学经济学学位和超过 50,000 名 Twitter 关注者，并且 谁还没有在这个系统中申请账户。”

零知识证明可以通过 SBT 计算来证明灵魂的特征（例如，它具有某些成员资格）。 该技术可以通过引入多方计算技术（例如乱码电路）进一步扩展，这可以使此类测试具有双重私密性：证明者不会向验证者透露他们是谁，并且验证者不会向证明者透露他们的验证机制。相反，双方一起进行计算，只能拿到输出结果。

另一种强大的技术是指定验证者证明。总的来说，“数据”具有滑溜溜的特性：如果我向您发送电影，我无法在技术上阻止您录制并将其发送给第三方。数字版权管理 (DRM) 等变通办法的有效性充其量是有限的，并且通常会给用户带来巨大的成本。然而，证明并非以同样的方式滑溜溜的。如果 Amma 想向 Bob 证明一些关于她的 SBT 的属性 X，她可以对“我持有满足属性 X 的 SBTs，或者我拥有 Bob 的灵魂的访问密钥”这一陈述进行零知识证明。 Bob 会认为这个陈述令人信服：他知道他没有做出证明，因此 Amma 实际上必须有满足性质 X 的 SBT。但是如果 Bob 将证明传递给 翠芬，翠芬不会被说服：据他所知， Bob 可以用他自己的密钥来证明。

这可以通过可验证的延迟函数 (VDF) 变得更加强大：Amma 可以制作并展示目前只能使用所需的 SBT 制作的证明，但其他任何人都可以在五分钟后制作。这意味着尽管不可能对原始数据本身（可能只是简单地复制和粘贴）拥有相同类型的有选择的权限，但可以表示对有关数据的可信证明的访问权限。尽管如此，这可能会让我们走得很远。正如区块链在交易中提供可追溯性以防止某人右键单击复制和粘贴有价值的 NFT（以及女巫攻击原始所有者）一样，SBTs 可以在社会传播中提供可追溯性，这至少可以通过未验证来源来降低复制-粘贴的价值。

这些示例的重点并不是要准确说明如何使用加密技术来解决 SBT 的所有隐私和数据许可问题。 相反，它是勾勒出几个例子来展示这些技术的力量。 一个重要的未来研究方向是确定不同类型数据许可的确切限制以及最适合实现所需许可级别的技术的特定组合。 另一个问题是需要什么样的多元财产制度来管理数据，以及如何正确地拆分访问（“usus”）、编辑（“abusus”）和获取现金流（“fructus”）权利。

7.2 作弊的灵魂

如果 SBT 是多种财产、网络商品和智能在其上协调的社会基础，人们可能会担心灵魂会试图欺骗或欺骗他们进入社区以获得我们想象 SBTs 允许的治理或财产权。例如，如果许多应用程序依赖于代表会议出席的 SBT，则不道德的会议可能会提供此类 SBTs 以换取贿赂。有了足够的贿赂，人类（和机器人）可以生成一个虚假的社交图谱，使该帐户看起来像一个真实的人类灵魂，并被（假的）SBTs 充分区分。就像 DAO 可以被贿赂一样，Souls 和他们使用的链上投票机制也可以。相反，如果 SBTs 用于降低协调性，灵魂可能会避免 SBTs 以最大化其影响。为什么我们应该相信灵魂拥有的 SBTs 准确地反映了他们真正的社会承诺，而不仅仅是他们选择如何玩这个游戏？

一个论点是，不同的作弊动机可能会“平衡”。灵魂可能会以适当的规模分类和自我识别到对他们来说很重要的网络中，就像哈伯格税收如何平衡对高估和低估资产的激励以得出大致准确的市场估值一样。 灵魂将希望持有更多的 SBTs 以在其社区内获得影响力，但另一方面，他们会避开他们不太关心的社区中的 SBTs，以在相关性指标上得分较低，并增加他们在更广泛网络治理中的影响力。

但是，如果假设这两种激励措施——获得访问权和最大化影响力——总是均匀地抵消，甚至接近于抵消，就好像施了魔法一样，那就太天真了。可能有许多社区使用 SBTs 以外的系统来控制访问和治理。或者社区可能——与我们关于公开的主要假设相反——发放私人 SBTs 以反映治理权，但诱使社区成员在更广泛的决策中对这些 SBTs 保密。

“欺诈”的问题不容小觑。这是一个重要的问题，解决它是未来研究的最重要的焦点之一。事实上，这就是为什么开源许多为人类用户优先或筛选的现有算法非常具有挑战性的一个主要原因。为了减轻和阻止 SBTs 中的欺诈，我们建议了几个规范和加密方向：

• SBT 的生态系统可以引导至“厚”的社区渠道，在这些渠道中，SBT 通过强大的社会纽带和重复互动表明真正的链下社区成员身份。 这将使社区更容易过滤和撤销冒充者和机器人的 SBT。 如此密集的渠道——我们经常在教堂、工作场所、学校、聚会团体和民间社会的组织中发现——将为在更“薄”的社交渠道中的监管游戏（例如，通过机器人、贿赂、冒充）提供更具抗女巫攻击的社会基础。

• 嵌套型社区可能需要 SBT 对“下方”的潜在共谋向量施加上下文。 例如，如果一个州正在举行一轮融资或投票，该州可能会要求每个参与的公民也持有一个确定的县和市的 SBT（州>县/市）。

• SBT 生态系统的开放性和密码学可证明性本身可用于主动检测合谋模式并惩罚不真实的行为——也许打折合谋灵魂的投票权，或迫使灵魂接受代表负面证明的 SBT。 例如，如果一个灵魂证明另一个灵魂是机器人，则案件可以升级并进行公开验证，导致该灵魂有大量负面证明。 这在 GitCoin QF 生态系统中已经在一定程度上发生了，其中使用一系列信号来检测“合谋团体”。

• ZK 技术（例如 MACI）可以通过密码学的防止灵魂做出的某些证明是可证实的。 这将使出售某些类型的证明的尝试变得不可信，因为贿赂者无法判断受贿者是否遵守了他们的交易。 已经有大量关于使用这种技术进行投票的研究，但最终任何非金融化的社会机制都可能最终受益于类似的想法。

• 我们可以鼓励举报人，以此来使大规模的串通变得不稳定。 我们不是检测和惩罚不正确或不良行为，而是检测和惩罚不良的模式。 由于存在虚假贿赂的可能性，这种技术有过度使用的风险，但它仍然是工具包的一部分。

• 我们可以使用来自同行预测理论的机制来鼓励在所有情况下都诚实报告，除非勾结非常大。 与会议证明与会者的出席不同，与会者可以证明彼此的出席，因此需要贿赂以证明虚假声明的与会者数量变得非常大。 奖励不一定是金钱，可以是 SBTs，这使得奖励对真正的社区成员比对攻击者更有用。

• 如果一群灵魂有共同的兴趣，我们可以使用专注于相关性的相关性分数。 例如，有界成对二次融资中使用的相关评分技术使用二次融资捐赠本身来确定两个参与者的相关性，从而确定他们的交集的折扣程度。 如果两个参与者有许多共同利益，他们向 QF 机制表达这一事实的动机肯定会随着相关性折扣而减少，但它永远不会变成零或负数。

8 比较与局限

虽然提出的身份框架的范围几乎是无限的，但在 web3 空间中有四个特别突出和相邻的范式被广泛讨论，值得比较：占主导地位的“传统”身份生态系统、假名经济、人格证明和可验证凭证。 每个范式都突出了我们所倡导的社会认同范式未来发展的重要贡献和挑战，我们将这些限制作为探索未来方向的跳板。 考虑到所有这些，我们还解释了为什么我们相信我们的灵魂和灵魂通证的社会身份原语是隐私制度的一条更有希望的前进道路。

8.1 传统

传统身份系统依赖于由第三方（政府、大学、雇主等）发行和调解的文件或身份证。通过调用第 3 方进行确认来确定出处。虽然遗留系统具有我们应该更深入地理解的一组有趣的属性，但这样的系统非常低效，并且不适合用于快速、高效协调的可组合性或计算。此外，这些系统缺乏社会背景，使灵魂依赖于一个集中的第三方来确认社区的成员身份，而不是嵌入社区。例如，大多数政府颁发的身份证明最终都可以追溯到医生和家庭成员授权签发的出生证明，他们是真相的最终来源，并且遗漏了许多同样有意义的社会联系，这些社会联系合起来提供了更强大的验证。事实上，当权力集中的中心寻求强有力的认同（例如，获得主要政府的安全许可）时，他们很少依赖此类文件，而是转向社交网络中的采访。因此，此类遗留身份系统倾向于将权力集中在发行人和那些能够进行尽职调查以获得更强大的验证的人身上，而这些人反过来又会成为刻板和不可靠的官僚机构。 DeSoc 的一个关键设计目标是确保能够满足和超过政府颁发的 ID 的安全要求，允许横向网络通过一系列社交基础为所有用户提供更高的安全性。

8.2 假名经济

Balaji Srinivasan 极大地推动了基于将声誉系统与零知识证明机制相结合以保护隐私的社会愿景，他创造并推广了“假名经济”一词。 他的早期版本强调使用假名来避免社会暴徒的歧视和“取消文化”（取消文化或呼吁文化是一个当代短语，用于指代一种排斥形式，在这种排斥形式中，某人被排除在社交或专业圈子之外——无论是在线、社交媒体还是面对面。 据说那些受到这种排斥的人已被“取消”），这些暴徒试图损害一个人的声誉并打破他们的社会联系。 它设想人们在他们的钱包中积累可转移的零知识 (ZK) 证明，并通过将证明子集转移到新钱包或将证明拆分到多个钱包中来逃避声誉攻击，这可能是没有可追溯性的。 在挑选要移植的证明时，一个人选择新帐户中所需的假名级别，权衡更多匿名性（移植较少的证明）或更多分布到他们的社交网络（移植更多的证明）之间的权衡。

典型的匿名经济提案与 DeSoc 之间的实际区别在于，我们不再强调身份分离是保护参与者免受滥用和取消文化的主要方式。 某种程度的分离（例如，家庭、工作、政治等之间的不同灵魂）可能是健康的，但一般而言，依靠建立新身份的能力作为抵御攻击的主要手段存在很大的缺点。 它使贷款和出处的声誉赌注变得更加困难，并且它与试图纠正相关性或 女巫攻击的治理机制的组合很差。

DeSoc 不会通过允许受害者以新的身份（如果已减少）重新出现在攻击中来保护受害者，而是允许其他方法，例如将攻击者情境化。 “取消”经常出现，因为当一个人或机器人与受害者几乎没有社交联系或背景时，声明和行动是脱离上下文并且病毒信号通过非上下文网络传播的。与 SBTs 提供出处以防止深度伪造的方式相同，SBT 的地图在社交上绘制了“热门作品”的起源。 “热门作品”本质上是在受害者社区之外产生的人工制品（由共享的 SBTs 成员资格反映），或者缺乏来自受害者社区的 SBTs 证明——这应该会让人怀疑该作品的真实性。 SBTs 还使受害者能够发起防御性反应，以抵消从他们的信任网络中策划和传播的打击（此处以共同持有 SBTs 的模式为代表）。通过维护社会背景，人们可以保持信任，即使他们面临取消的威胁，并追究攻击者的责任。改善出处可以改善真理的社会基础。

8.3 人格证明

人格证明协议 (PoP) 旨在提供个人唯一性的通证，以防止女巫攻击，同时允许非金融化应用程序。 为此，他们依赖于社交图谱的全局分析、生物识别、同步的全球关键方或它们的某种组合等方法。 然而，由于 PoP 协议寻求代表个人身份——专注于实现全球唯一性——而不是映射关系和团结的社会身份，所以 PoP 协议仅限于对所有人一视同仁的应用程序。 我们感兴趣的大多数应用程序（例如声誉质押）都是希望每个用户都是独特的、与众不同的人。

此外，PoP 协议也不能免受女巫攻击。 在几乎所有近期可预见的应用中，PoP 系统可能会遭受女巫攻击，只是成本略高。 除非地球上的大多数人都注册了 PoP 服务并且正在参与特定的验证活动，否则攻击者总是可以招募尚未参与的不感兴趣的人充当女巫。 虽然这样的雇佣兵并不完全是机器人，但区别只是表面的，可能只是增加了一点点费用。

许多 PoP 协议旨在为构建普遍基本收入或全球民主建立基础。 虽然我们的野心不同，但此类协议仍促使我们考虑如何逐步构建以协调多种网络产品。 与 PoP 的二元、个人主义和全球性质相比，我们的方法旨在为自下而上的声誉、财产和治理构建一个丰富的、上下文相关的和分层的基础，允许参与各种大小的社区和网络。

8.4 可验证凭证

可验证凭证 (VC) 是 W3C 标准，其中凭证（或证明）可根据持有者的判断进行 zk 共享。 VC 强调了我们基础隐私范式的主要局限性，并激发了我们对上述隐私扩展的讨论。 在 SBT 具有缩小宣传范围的隐私扩展之前，VC 和 SBTss 可以被视为自然的补充：特别是，SBTs 最初是公开的，因此它们不适用于政府颁发的身份证明等敏感信息，而 VC 的实施一直在努力寻找一种恢复范式，这可能是由社区恢复解决。 在短期内，这两种方法结合起来可能比单独使用任何一种方法都更强大。 但是 VC 也有一个关键的限制：至少在它们的标准化形式上，VC 不支持我们列举的大多数应用程序，因为它们具有单方面的隐私性。

在我们的用例中，单方面 zk 共享与激励不兼容，也不反映我们关于隐私的规范。我们的大多数应用程序都依赖于某种程度的宣传。但是在 zk-sharing 下，灵魂无法知道另一个灵魂拥有 SBT，除非它被共享给他们——这使得声誉赌注、可信承诺、抗女巫治理和简单的租赁合同（例如公寓租赁）无法摆脱不一定是可见的其他承诺和产权负担。更深入地说，我们怀疑单方面的可共享性被视为正确的隐私范式。多方关系中的一方很少有未经另一方同意而单方面披露关系的权利。正如单方面可转让的私有财产不是丰富的财产制度一样，简单的单方面可共享性也不是非常丰富的隐私制度。如果两方共同拥有一项资产并选择通过 VC 代表他们的关系，则这种凭证不允许相互同意和相互许可。这个问题涉及到更复杂的多元财产和复杂的组织形式和权限的情况，这是 DeSoc 的一个特点。

9 灵魂诞生

从当前的 web3 生态系统到由 SBTs 介导的增强社交的路径面临着典型的冷启动挑战。 一方面，SBTs 不可转让。 另一方面，今天的钱包组合可能不是 SBTs 的最终归宿，因为它们缺乏社区恢复机制。 但为了让社区恢复钱包发挥作用，他们需要跨不同社区的各种 SBTs 来保证安全。 首先要做是什么：SBTs 还是社区恢复？ 谁是早期接纳SBTs 的社区？ 不同链上的 SBTs 如何互操作？ 我们不能渴望知道所有的可能性和答案，而是勾勒出一些有希望的路径供读者在当前的 web3 甚至 web2 架构中进一步探索。

9.1 SBTs 原型

尽管 SBT 的标志是不可转让性，但 SBT 可能还具有另一个可能被证明在其启动中更有用的属性：可撤销性。 SBT 有可能首先孕育为可撤销、可转让的通证，然后才发展为不可转让。如果发行者可以销毁令牌并将其重新发行到新钱包，则令牌是可撤销的。例如，当密钥丢失或泄露时，燃烧和重新发行是有意义的，并且发行人有兴趣确保通证不会被金融化并出售给一方 —— 换句话说，当通证表明真正的社区成员身份时，具有重复链下互动的雇主、教堂、聚会团体、俱乐部很容易销毁和重新发行通证，因为它们与人有关系，并且可以通过电话、视频会议或简单的面对面会议。单一的互动，例如参加音乐会或会议，不太适合，因为社区纽带较弱。

可撤销、可转让的通证是一种原型 SBT——在灵魂出生之前提供支持性的胎盘功能。些通证为钱包争取时间来孕育安全的社区恢复机制，以及让人们积累积累的原始 SBT，这些原始 SBT 最终可以被烧毁并重发为不可转让的 SBT。在这条路径下，问题不是“首先会发生什么：SBT 还是社区恢复？” 相反，SBT 和社区恢复同时实现，产生了一个灵魂。

9.2 社区恢复钱包

尽管今天的钱包缺乏社区恢复能力，但它们在成为 SBT 的家——或者可能是妊娠子宫——方面都有相对的优势和劣势。 人格证明 (PoP) 协议的优势在于已经在尝试社会争议解决机制，这是社区恢复的基础。 此外，许多 DAO 使用 PoP 来促进治理，使其自然成为 SBT 的第一发行者。 然而，尽管 PoP 自然领先，但 PoP 协议尚未赢得广泛信任来存放有价值的通证资产，而托管型钱包则有。

托管钱包——尽管存在中心化缺陷——可能因此为不太成熟的零散用户提供了一个自然的入口。 此类托管钱包还可以为零售社区构建工具，以发行可撤销的通证，这些通证随后会转换（或销毁和重新发行）为 SBTs，甚至可以为更多“企业”发行人提供工具——其中许多人正在寻找在 web3 中建立忠诚客户群的方法，但 缺乏监管方面的专业知识。 一旦社区恢复机制正式确定并经过实战考验，这些托管钱包可以分散到社区恢复中，而托管人则继续在 DeSoc 中提供其他有价值的服务（如社区管理、SBTs 发行等）。

对于更成熟的 web3 用户，去中心化的非托管钱包（或像 Argent 和 Loopring 这样的非托管社交恢复钱包）是引导社区恢复机制的自然起点。 非托管钱包具有原生 web3 开源的优势，以及预先宣布和逐步试验机制的灵活性，以向自愿的、成熟的用户子集进行测试激励和混合机制（例如：多签）。 所有这些方法（PoP、托管和非托管）在试验和引导具有不同复杂程度和风险承受能力的用户方面发挥着重要作用。

9.3 灵魂原型

规范也可以引导灵魂存在。 当我们重新考虑通证和钱包时，我们还可以重新定义我们对某些类别的 NFT 和旨在表明会员资格的通证的看法。 特别是，我们可以引入不转移由信誉良好的机构颁发的 NFT 和 POAP 这一规范，这些机构反映了出席会议、工作经验或教育证书。 这种会员通证的转移——如果进行价值交易——可能会降低钱包的声誉，并可能阻止发行人进一步向该钱包发行会员或 POAP 通证。 在非托管生态系统中，大量用户已经获得了显着的财务声誉和钱包中的stake，这可以作为有效的抵押品引导他们不要滥用不可转让的期望。

虽然所有这些途径都有各自的挑战，但我们希望通过各种方法，经过逐步迭代，在中期收敛到一个准平衡状态。

10 结论

尽管我们一直在想象 DeSoc 可以实现什么，但在许多方面，上述只是第一步。 通往 DeSoc 的道路不止一条，包括许多基于非区块链的框架，例如 Spritely、ACDC 和 Backchannel，它们依赖于与本地机器而不是全球账本（区块链）的数据存储。 这些框架最终可能会在跨社交距离上提供更大的信任，因为它们可以利用信任关系的传递性——比如受信任的介绍——而不是依赖于知名的高地位机构（如大学或 DAO）发布的 SBTs。 此外，我们上面描述的应用程序只是 DeSoc 能够增强能力的开始，而不涉及虚拟世界：它们的物理、社会以及它们与真实世界的复杂交集。 所有这些都表明，即使是我们在上面描绘的广泛野心，也只是 DeSoc 最终可能成为的开始。

然而，在这条道路上，仍然存在许多挑战和悬而未决的问题。 上述草图需要大量的红队（竞争对手），其中许多比完全规范更像是建议。 DAO 如何在仔细比较 SBTs 中的灵魂模式和相关性，以执行女巫攻击的保护和去中心化的同时保持其状态宣传？ 面对各种相关贴现方案，获得 SBTs 的激励兼容性如何？ 隐私与相关折扣和其他 DeSoc 机制设计有多少冲突？ 我们如何以一种社会性的但又适当的私人方式来衡量不平等？ 继承在社区恢复框架中应该如何工作？ 是否有可以绘制甚至纳入协议的红线以避免反乌托邦情景？ 还是我们应该首先竞相构建最佳场景？ 这些问题只是我们期望的多年研究议程的开始，该议程将与 DeSoc 生态系统共同发展。

然而，DeSoc 的潜力似乎不仅值得为应对这些棘手的挑战付出代价，而且可能是确保我们生存所必需的。 阿尔伯特·爱因斯坦在 1932 年的会议上说，“人的组织能力”未能跟上“他的技术进步”的步伐，这让“一个 3 岁的孩子手里拿着一把剃刀”。 在一个他的观察似乎比以往任何时候都更有先见之明的世界里，学习如何为可编程社会编写未来——而不是将其写在主观信任之上——似乎是人类在这个星球上生存下去的必修课。

国内用户请加微信：19726581

Authors: leeduckgo,msfew

0x01 Web3 dApp Dev Camp

1.1 Background

0x01. Web3.0 is the next-generation Web paradigm, and Web3.0 dApp is the next-generation blockchain application paradigm. There are many new opportunities in both areas

0x02. Currently, there is a degree of disconnection between the Chinese and international software development industry, tech and blockchain community. The purpose of the Web3.0 dApp Dev Camp is to help developers including blockchain developers and students access the most cutting-edge and coolest blockchain development tools and blockchain development paradigms.

1.2 Mission

Web3 dApp Dev Camp is an online version of the Github Discussion-based, Project-oriented online bootcamp, designed to enable "traditional software developer, college students, and blockchain developers" to quickly learn how to develop on Ethereum-compatible chains (e.g. Moonbeam, Polygon) with Web3.0 dApp development skills.

1.3 Main Tasks

1.3.1 Ethereum basics with eth.build

• A visual understanding of blockchain fundamentals with eth.build

  English: https://mirror.xyz/0x769699506f972A992fc8950C766F0C7256Df601f/xcUOEKghOqaBJ3jDv7Spec__NjMChsey2y37yQkDoNM

  Chinese: https://mp.weixin.qq.com/s/wAoaFu6ql0HfR-LETGQ2DA

• Calling smart contracts with eth.build

  Chinese: https://github.com/WeLightProject/Web3-dApp-Camp/discussions/6

• Implementing blockchain explorer with eth.build

  Video: https://ke.qq.com/course/3616174/11969953598483886?tuin=d34bd514

1.3.2 Intro to scaffold-eth framework

• Scaffold-eth Quick Intro | Web3.0 dApp Dev 0x03

  English: https://mirror.xyz/0x769699506f972A992fc8950C766F0C7256Df601f/FxjGNBnf6IqPwf9BTObNktCrkkPfwfVo0khHmBui6fU

  Chinese: https://mp.weixin.qq.com/s/72gzBaLNA0ruHSPsVBPtmQ

• Get & Set Value 1.0 | Web3.0 dApp Dev 0x04

  English: https://mirror.xyz/0x769699506f972A992fc8950C766F0C7256Df601f/iqlB8bddq3Rgv7fFc455OfqMNDf6M0hIEo1dWqlkohY

  Chinese: https://mp.weixin.qq.com/s/cCWNOvkAiJQQkF9Bvpnz_Q

• Get & Set Value 2.0 | Web3.0 dApp Dev 0x05

  English: https://mirror.xyz/0x73c7448760517E3E6e416b2c130E3c6dB2026A1d/b2Pz3Cxq3A9bjKWNlkgEqStZaMc6w89Cupgw9CcsPSs

  Chinese: https://mp.weixin.qq.com/s/gbnGsiBIFZhm1iydBPvBXg

• Get & Set Value 3.0 | Web3.0 dApp Dev 0x06

  English: https://mirror.xyz/0x73c7448760517E3E6e416b2c130E3c6dB2026A1d/HvS9-pIa1raDuBUCaKGDZUpkFqElUX0fZpMkjoe5HQA

  Chinese: https://mp.weixin.qq.com/s/yVUv9CT-rPbPlwZ2g6iqSA

1.3.3 DeFi

• Token vendo | Web3.0 dApp Dev 0x08

  English: https://mirror.xyz/0x73c7448760517E3E6e416b2c130E3c6dB2026A1d/_4PIlD_3kjSqx80Fs4n0EGRk2NUEQfL5qFXpMjzy8Bo

  Chinese: https://mp.weixin.qq.com/s/FpAQlqWoxXyVVKzDg9vHvQ

1.3.4 NFT

Work in progress

• Build SVG NFT dApp by Scaffold-Eth | Web3.0 dApp Dev 0x07

  English: https://mirror.xyz/0x73c7448760517E3E6e416b2c130E3c6dB2026A1d/kYL1EO8ZlksLdRTUBzoY-aPI6VkgBs-NIoFS8Qmc2rk

  Chinese: https://mp.weixin.qq.com/s/WvTFk3E6FjfHtXfp2uHkrw

• Voxel Art NFT dApp Development Series

Youtube:

https://www.youtube.com/channel/UCHFdayIAxLY3DEEMOz1142Q

Discussion:

https://github.com/WeLightProject/Web3-dApp-Camp/discussions/68

1.4 Task: Elixir

https://github.com/WeLightProject/Web3-dApp-Camp/discussions/categories/projects-elixir

1.5 Focus Area: Moonbeam

Moonbeam is a supporting partner for NonceGeek.

https://github.com/WeLightProject/Web3-dApp-Camp/discussions/categories/projects-moonbeam

0x02 Materials

Materials are blockchain-related materials contributed by members.

https://github.com/WeLightProject/Web3-dApp-Camp/discussions/categories/materials

0x03 Workshop

Web3 dApp Dev Workshop is an AFK version, which is based on "desktop game concept" and emphasizes "experience":

Workshop members are mainly Nonce Geek Studio members, and will also invite few external members to participate (targeted invitations or paid access).

• 1st Workshop:

  [Summary] Generating game maps based on on-chain data @ Workshop 0x01

  https://mp.weixin.qq.com/s/u8ayW5-SbQSK_Kd5oUySRQ

---

中文用户请加微信：197626581

Author: Fenix

Translator: Snowyaya, msfew

Livebook Version: https://github.com/zhenfeng-zhu/ex_chain

Tutorial Video:

https://ke.qq.com/course/3616174?tuin=d34bd514&taid=13066085086997934

Histories of this Branch:

https://github.com/WeLightProject/Web3-dApp-Camp/discussions/31

https://github.com/WeLightProject/Web3-dApp-Camp/discussions/32

0x01 Why Elixir

Elixir is a dynamic, functional language for building scalable and maintainable applications.

https://elixir-lang.org/

1.1 Amazing Syntax

Elixir's syntax is a tribute to Ruby with a touch of Erlang. The design of any language syntax is inseparable from the preferences and goals of its authors, and Elixir's authors were core developers in the Rails community, so the syntax is naturally very Ruby. Of course, Elixir, which is rooted in Erlang, has many of its own features.

What's most endearing is the pipe |>, which turns layers of backwards-thinking function calls into a more intuitive representation, for example, we often write code like this:

IO.puts(format(to_map(Store.get_host(host))))

or

list_data = Store.get_host(host)
map = to_map(list)
formatted_output = format(map)
IO.puts(formatted_output)

Such code could be written in Elixir as:

host
|> Store.get_host
|> to_map
|> foramt
|> IO.puts

Very clear! Most importantly, it fits more into your mindset and makes it easier to get the code flowing at your fingertips. When we write code, it is basically a process of constant "partitioning": breaking down big problems into small ones, and small problems into even smaller ones, and finally solving them. And Elixir gives you a high degree of consistency in your code and your thinking.

pipe is very flexible. You can organize your ideas and combine functions at the same time. This is a bit of like building blocks.

1.2 Pattern Matching

Anyone who has learned a little bit of programming should know that = is the assignment operator in most programming languages. Even if this is not the case, there is a similar symbol with a variable on its left and a constant assigned to it on its right. Other variables or some operations such as: a = 1 or a = max(number_list).

However, in Elixir, = is the match operator.

iex>a = 1
1
iex>1 = a
1
iex>2 = a
** (MatchError) no match of right hand side value: 1

Elixir's pattern matching and recursion work really well together. There is no need to use the if else flow to determine the boundary values, and the code is expressed quite elegantly.

I think that recursion can be said to be a very good representation of the First Principle principle. Only by looking at the nature of data processing can we understand recursion. Let's take a look at one of the best quotes from the book.

L. Peter Deutsch once penned, “To iterate is human, to recurse divine.”

As an example to get a feel for it:

defmodule Recursion do
  def sum(0), do: 0
  def sum(n), do: n + sum(n - 1)
end

IO.puts Recursion.sum(5)  # => 15

This function calculates the sum of all positive integers under a given number. The above example is calculating 5+4+3+2+1+0.

Replacing most conditional branches with pattern matching is a great thing: the simplicity of the code goes without saying, and its efficiency can be further optimized. If/else is a sequential logic, and because of the flexibility of its syntax (everyone does it to have the if condition as a function), it can be optimized for special cases using jump tables, most of which are O(N) and difficult to handle in parallel. While pattern matching due to its syntactic limitations, many cases can be optimized into a decision tree, the time complexity is O(logN), and there is room for parallel processing optimization in the future.

1.3 Macro

Many people see a macro and think it represents some kind of mysterious power.

In fact, we can think of a macro as a special function that accepts a syntax tree (one or more) as an argument and then returns a syntax tree.

Is the defmodule block a syntax? No, it is a macro. is a def block a syntax? No, it is still a macro.

x in [1, 2, 3] # => true

This should be a syntax now, right? No, even in is a macro.

1.4 Born with Concurrent Support

Elixir is built on top of Erlang and eventually compiles into fully equivalent bytecode modules that can call each other.

Erlang's actor-based concurrency model, let it crash idea, supervisory tree, error handling, are the best practices that have been summed up during the struggle with concurrency for more than 20 years, both ideologically and practically. Elixir stands on the shoulders of giants and enjoys its success.

1.5 Full Toolchain

Since the 21st century, emerging languages have also gone all out on the toolchain, which has (almost) become part of the language rather than an appendage.

Elixir carries its own mix -- from project creation and scaffolding (mix new), to compilation (mix compile), to testing (mix test), to documentation (mix doc), to dependency management (mix deps), all wrapped up.

Reference: elixir: panacea? or in vain?

1.6 Livebook

Livebook is an interactive and collaborative code notebook for writing for Elixir. It can be compared to Python's jupyter notebook.

https://livebook.dev/

Mix.install/2

We can install the dependencies via Mix.install/2.

:force - if true, removes install cache. This is useful when you want to update your dependencies or your install got into an inconsistent state (Default: false)

:verbose - if true, prints additional debugging information (Default: false)

Mix.install(
  [:poison, :req]
  # force: true,
  # verbose: true
)

:ok

%{hello: "world", arr: [1, 2, 3]}
|> Poison.encode!()
|> IO.inspect()

"{\"hello\": \"world\",\"arr\": [1, 2, 3]}"
|> Poison.decode!()
|> IO.inspect()

"{\"hello\":\"world\",\"arr\":[1,2,3]}"
%{"arr" => [1, 2, 3], "hello" => "world"}

%{"arr" => [1, 2, 3], "hello" => "world"}

Req.get!("https://api.github.com/repos/elixir-lang/elixir").body["description"]

"Elixir is a dynamic, functional language designed for building scalable and maintainable applications"

More fun examples can be found at: https://github.com/wojtekmach/mix_install_examples

0x02 Blockchain Introduction

2.1 Block

The easiest and quickest way to understand what a block really is is to analyze its data structure, using the example of block #514095 in Bitcoin:

{
  "hash": "00000000000000000018b0a6ae560fa33c469b6528bc9e0fb0c669319a186c33",
  "confirmations": 1009,
  "strippedsize": 956228,
  "size": 1112639,
  "weight": 3981323,
  "height": 514095,
  "version": 536870912,
  "versionHex": "20000000",
  "merkleroot": "5f8f8e053fd4c0c3175c10ac5189c15e6ba218909319850936fe54934dcbfeac",
  "tx": [
    // ...
  ],
  "time": 1521380124,
  "mediantime": 1521377506,
  "nonce": 3001236454,
  "bits": "17514a49",
  "difficulty": 3462542391191.563,
  "chainwork": "0000000000000000000000000000000000000000014d2b41a340e60b72292430",
  "previousblockhash": "000000000000000000481ab128418847dc25db4dafec464baa5a33e66490990b",
  "nextblockhash": "0000000000000000000c74966205813839ad1c6d55d75f95c9c5f821db9c3510"
}

In the structure of this Block, previousblockhash and merkleroot are the two most important fields. The former is a hash pointer, which is actually a hash of the previous Block, and through the previousblockhash we can recursively find all the Blocks, i.e., the entire chain; The latter is the root of a Merkle tree, which contains all the transactions in the entire Block. By saving the merkleroot, we can ensure that no transaction in the current Block will be modified.

Ethereum's blockchain model is very different from Bitcoin's, but it has similar information in its Block structure.

{
   "jsonrpc":"2.0",
   "result":{
      "author":"0x00d8ae40d9a06d0e7a2877b62e32eb959afbe16d",
      "difficulty":"0x785042b0",
      "extraData":"0x414952412f7630",
      "gasLimit":"0x47b784",
      "gasUsed":"0x44218a",
      "hash":"0x4de91e4af8d135e061d50ddd6d0d6f4119cd0f7062ebe8ff2d79c5af0e8344b9",
      "logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
      "miner":"0x00d8ae40d9a06d0e7a2877b62e32eb959afbe16d",
      "mixHash":"0xb8155224974967443d8b83e484402fb6e1e18ff69a8fc5acdda32f2bcc6dd443",
      "nonce":"0xad14fb6803147c7c",
      "number":"0x2000f1",
      "parentHash":"0x31919e2bf29306778f50bbc376bd490a7d056ddfd5b1f615752e79f32c7f1a38",
      "receiptsRoot":"0xa2a7af5e3b9e1bbb6252ba82a09302321b8f0eea7ec8e3bb977401e4f473e672",
      "sealFields":[
         "0xa0b8155224974967443d8b83e484402fb6e1e18ff69a8fc5acdda32f2bcc6dd443",
         "0x88ad14fb6803147c7c"
      ],
      "sha3Uncles":"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
      "size":"0x276",
      "stateRoot":"0x87e7e54cf229003014f453d64f0344e2ba4fc7ee3b95c7dd2642cca389fa1efe",
      "timestamp":"0x5a10968a",
      "totalDifficulty":"0x1804de0c47ffe1",
      "transactions":[...],
      "transactionsRoot":"0xc2091b032961ca23cf8323ea827e8956fe6dda9e68d75bcfaa8b910035397e35",
      "uncles":[]
   },
   "id":1
}

parentHash and transactionsRoot correspond to the previousblockhash and merkleroot in Bitcoin, respectively. These two are very important in the whole blockchain network.

2.2 Hash Pointer

The hash pointer in the Block structure has two roles in the blockchain; it not only connects different blocks, but also validates the Block to ensure that the data in the Block is not tampered with by other malicious nodes.

!Unsupported embed

Except for the first Block, the prev_hash in each Block is the hash of the previous Block. If a node wants to modify the transaction of a Block on the main chain, it will change the hash of the current Block. If a node wants to modify the transaction of the Block on the main chain, it will change the hash of the current Block, and the later Block will have no way to find the previous chain through prev_hash. So the current node will be discovered by other nodes if it tampers with the transaction.

2.3 Merkle Tree

Another field merkleroot is actually the root node of a Merkle tree, which is actually a data structure connected using a hash pointer; although Merkle trees have leaf and non-leaf nodes, it only stores data in the leaf nodes. However, only the leaf nodes store data, and all non-leaf nodes are hashes used to verify data integrity.

!Unsupported embed

All transactions in each Block are stored in this Merkle tree and the merkleroot is stored in the Block's structure. This ensures that any transaction tampering in the current Block can be detected immediately.

2.4 Summary

prev_hash and merkleroot ensure that all blocks and transactions are connected by means of "pointers" respectively, which ultimately ensures that blocks and transactions are not tampered with by malicious nodes or attackers, and almost all blockchain projects use similar methods to connect different blocks and transactions. This can be said to be the infrastructure and standard for blockchain projects.

Reference: Draveness's blog

0x03 Create a block

3.1 Block

A basic block structure is as follows:

%{
  :index => 0,
  :timestamp => "",
  :name => "",
  :previous_hash => "",
  :current_transactions => []
}

• index: index of the current block

• timestamp: the time when the block was generated

• name: the name of the block

• previous_hash: hash of the previous block

• current_transactions: the transactions of the current block

At this point, the concept of a blockchain should be obvious: each new block contains a hash of the previous block within it.

This is critical because it is the reason why the blockchain is immutable. If an attacker corrupts an earlier block in the blockchain, all subsequent blocks will contain incorrect hashes. Does this make sense? If you haven't figured it out yet, take some time to think about it carefully.

This is the core idea behind the blockchain.

The basic structure of the program is as follows:

defmodule Blockchain do
  defstruct chain: [], current_transactions: []

  def new_block(c, name) do
  end

  def zero() do
  end

  def last_block(c) do
  end

  def hash(block) do
  end
end

warning: variable "c" is unused (if the variable is not meant to be used, prefix it with an underscore)
  share.livemd#cell:4: Blockchain.new_block/2

warning: variable "name" is unused (if the variable is not meant to be used, prefix it with an underscore)
  share.livemd#cell:4: Blockchain.new_block/2

warning: variable "c" is unused (if the variable is not meant to be used, prefix it with an underscore)
  share.livemd#cell:10: Blockchain.last_block/1

warning: variable "block" is unused (if the variable is not meant to be used, prefix it with an underscore)
  share.livemd#cell:13: Blockchain.hash/1

{:module, Blockchain, <<70, 79, 82, 49, 0, 0, 9, ...>>, {:hash, 1}}

3.2 Complete the Program

Completes the new_block function:

def new_block(c, name) do
    b = %{
      :index => length(c.chain),
      :timestamp => NaiveDateTime.utc_now(),
      :name => name,
      :previous_hash => c |> last_block() |> hash(),
      :current_transactions => c.current_transactions
    }

    %{c | chain: c.chain ++ [b], current_transactions: []}
end

• Compute the hash of the previous block and write it to the previous_hash

• %{c | chain: c.chain ++ [b], current_transactions: []} is a syntax sugar that appends the current block to the chain.

Elixir hash to be done with the :crypto.hash function like:

value = "fenix"

:crypto.hash(:sha256, value)
|> Base.encode16()
|> String.downcase()

"b170f30d201da73b7637e94391f22a4642f8c396f9c1c9f8b2799919ced46d78"

The complete program is as follows:

defmodule Blockchain do
  defstruct chain: [], current_transactions: []

  def new_block(c, name) do
    b = %{
      :index => length(c.chain),
      :timestamp => NaiveDateTime.utc_now(),
      :name => name,
      :previous_hash => c |> last_block() |> hash(),
      :current_transactions => c.current_transactions
    }

    %{c | chain: c.chain ++ [b], current_transactions: []}
  end

  def zero() do
    b = %{
      :index => 0,
      :timestamp => NaiveDateTime.utc_now(),
      :name => "ZERO",
      :previous_hash => "",
      :current_transactions => []
    }

    %Blockchain{
      chain: [b],
      current_transactions: []
    }
  end

  def last_block(c) do
    c.chain |> Enum.reverse() |> hd()
  end

  def hash(block) do
    value = block |> Poison.encode!()

    :crypto.hash(:sha256, value)
    |> Base.encode16()
    |> String.downcase()
  end
end

{:module, Blockchain, <<70, 79, 82, 49, 0, 0, 14, ...>>, {:hash, 1}}

3.3 Try and Generate Genesis Block

Genesis Block

zero = Blockchain.zero()

%Blockchain{
  chain: [
    %{
      current_transactions: [],
      index: 0,
      name: "ZERO",
      previous_hash: "",
      timestamp: ~N[2022-04-01 12:17:21.126190]
    }
  ],
  current_transactions: []
}

Create more blocks

zero
|> Blockchain.new_block("first")
|> Blockchain.new_block("second")
|> Blockchain.new_block("third")

%Blockchain{
  chain: [
    %{
      current_transactions: [],
      index: 0,
      name: "ZERO",
      previous_hash: "",
      timestamp: ~N[2022-04-01 12:17:21.126190]
    },
    %{
      current_transactions: [],
      index: 1,
      name: "first",
      previous_hash: "dd9a0b7a81ba060c2d1cd7e581ad0bda35c7019831049b39dbcc1c35a8f3f131",
      timestamp: ~N[2022-04-01 12:17:35.067392]
    },
    %{
      current_transactions: [],
      index: 2,
      name: "second",
      previous_hash: "f93e075bef13d86514a77d407e36ac9d3b2636769bfe483a3ecc4a2afd5b88ac",
      timestamp: ~N[2022-04-01 12:17:35.067467]
    },
    %{
      current_transactions: [],
      index: 3,
      name: "third",
      previous_hash: "0ac2d3ec623b955ef6781ff130f6aa8f65b1dd1022f9c7f6a60d40ee03ed3c8a",
      timestamp: ~N[2022-04-01 12:17:35.067551]
    }
  ],
  current_transactions: []
}

0x04 Realization of Transactions

The word 'transaction' in blockchain is confusing and seems to represent a conversion that necessarily involves money.

In reality, we should abstract transactions to the following abstract model:

{
    from: from_addr,
    to: to_addr,
    amount: amount, # Only for public blockchains
    gas: gas, # transaction service fee
    op: operation # Operations done with the transaction
}

In a public blockchain, each transaction will contain an amount (the amount may be 0) and gas. Some transactions are simply user-to-user transfers, and some transactions are keyed to operation. In this case, to is usually a contract address, and operation tells the "blockchain computer" what to do - for example, to store a value in the blockchain database, or to perform some computation on the blockchain - and we think of the blockchain as a "distributed computer".

In federated chains, the concept of amount is deprecated, and there are no more transactions for native token transfers (note that smart contract-based tokens like ERC20 are supported, though they are often referred to as credits). However, gas still exists and is used to measure the consumption of computational resources.

The format of a transaction in Elixir can be abstracted as follows:

%{
  :sender => sender,
  :recipient => recipient,
  :amount => amount
}

Completes the new_transaction function:

def new_transaction(c, sender, recipient, amount) do
    tx = %{
      :sender => sender,
      :recipient => recipient,
      :amount => amount
    }

    %Blockchain{c | current_transactions: c.current_transactions ++ [tx]}
end

The complete code for our transactions is as follows:

defmodule Blockchain do
  defstruct chain: [], current_transactions: []

  def new_block(c, name) do
    b = %{
      :index => length(c.chain),
      :timestamp => NaiveDateTime.utc_now(),
      :name => name,
      :previous_hash => c |> last_block() |> hash(),
      :current_transactions => c.current_transactions
    }

    %{c | chain: c.chain ++ [b], current_transactions: []}
  end

  def zero() do
    b = %{
      :index => 0,
      :timestamp => NaiveDateTime.utc_now(),
      :name => "ZERO",
      :previous_hash => "",
      :current_transactions => []
    }

    %Blockchain{
      chain: [b],
      current_transactions: []
    }
  end

  def new_transaction(c, sender, recipient, amount) do
    tx = %{
      :sender => sender,
      :recipient => recipient,
      :amount => amount
    }

    %Blockchain{c | current_transactions: c.current_transactions ++ [tx]}
  end

  def last_block(c) do
    c.chain |> Enum.reverse() |> hd()
  end

  def hash(block) do
    value = block |> Poison.encode!()

    :crypto.hash(:sha256, value)
    |> Base.encode16()
    |> String.downcase()
  end
end

{:module, Blockchain, <<70, 79, 82, 49, 0, 0, 16, ...>>, {:hash, 1}}

4.1 Try and create transaction

Genesis block

zero = Blockchain.zero()

%Blockchain{
  chain: [
    %{
      current_transactions: [],
      index: 0,
      name: "ZERO",
      previous_hash: "",
      timestamp: ~N[2022-04-01 12:20:26.788775]
    }
  ],
  current_transactions: []
}

Execute a few transactions and pack into a new block

zero
|> Blockchain.new_transaction("alice", "bob", 100)
|> Blockchain.new_transaction("alice", "bob", 20)
|> Blockchain.new_block("first")

%Blockchain{
  chain: [
    %{
      current_transactions: [],
      index: 0,
      name: "ZERO",
      previous_hash: "",
      timestamp: ~N[2022-04-01 12:20:26.788775]
    },
    %{
      current_transactions: [
        %{amount: 100, recipient: "bob", sender: "alice"},
        %{amount: 20, recipient: "bob", sender: "alice"}
      ],
      index: 1,
      name: "first",
      previous_hash: "56881bced4dd4b52f76cc75e0b7f217fe4696e3e15974d4c174d84fb4205b92a",
      timestamp: ~N[2022-04-01 12:20:39.174474]
    }
  ],
  current_transactions: []
}

The transaction now is in the first block.

0x05 Proof of Work (PoW)

The concept was widely spread because Bitcoin adopted the PoW consensus mechanism. The full name of PoW is Proof of Work. The PoW consensus mechanism is actually a design idea rather than a specific implementation.

The PoW mechanism was first proposed as early as 1997, and it was mostly used in the scenario of resisting abuse of software services in the early days such asanti-spam (that's why PoW is involved in the mail service system).

We'll use a Wikipedia diagram to explain how the PoW mechanism is used in this scenario.

In order to prevent the spread of spam messages, the receiver does not directly accept the message from any sender. Therefore, in a valid conversation, the sender needs to calculate an answer to the problem according to the rules, and send it to the receiver at the same time. The answer needs to be verified with it. If the answer is verified as valid, then the recipient will accept the message.

!Unsupported embed

可以看出 PoW 的核心设计思路是提出一个计算难题，但是这个难题答案的验证过程是非常容易的，这种特性我们称之为计算不对称特性

5.1 How to understand PoW in blockchain

As an example, let's say we are given a string "Fenix" and the problem we pose is, to compute a number, concatenated with the given string, so that the first 4 bits of the SHA256 result of this string are 0. We call this number nonce, such as the string "Fenix1234", nonce is 1234 and we want to find the nonce that meets the criteria.

An Example in Python

#!/usr/bin/env python
import hashlib

def main():
    base_string = "Fenix"
    nonce = 10000
    count = 0
    while True:
        target_string = base_string + str(nonce)
        pow_hash = hashlib.sha256(target_string).hexdigest()
        count = count + 1
        if pow_hash.startswith("0000"):
            print pow_hash
            print "nonce: %s  scan times: %s" % (nonce, count)
            break
        nonce = nonce + 1

if __name__ == '__main__':
    main()

The base string is specified as "Fenix", and the nonce starts to search up from 10000, until a matching nonce value is found.

# The first 4 digits are 0000
0000250248f805c558bc28864a6bb6bf0c244d836a6b1a0c5078987aa219a404
nonce: 68828  scan times: 58829
# The first 5 digits are 00000
0000067fc247325064f685c32f8a079584b19106c5228b533f10c775638d454c
nonce: 1241205  scan times: 1231206
The first 7 digits are 0000000
00000003f41b126ec689b1a2da9e7d46d13d0fd1bece47983d53c5d32eb4ac90
nonce: 165744821  scan times: 165734822

Each time the first N bits of the hash result are required to have one more 0, the number of calculations is many times more. When the first 7 bits are required to be 0, the number of computations reaches 160 million.

Reference: 《深入浅出区块链》

5.2 Other languages

5.2.1 Go

package main

import (
    "crypto/sha256"
    "encoding/hex"
    "fmt"
    "strconv"
    "strings"
)

func main() {
    pow("0000")
}

func pow(diff string) {
    baseStr := "fenix"
    nonce := 0
    count := 0
    for {
        targetStr := baseStr + strconv.Itoa(nonce)
        h := sha256.New()
        h.Write([]byte(targetStr))
        powHash := hex.EncodeToString(h.Sum(nil))
        fmt.Printf("\r%s", powHash)
        count += 1
        if strings.HasPrefix(string(powHash), diff) {
            fmt.Println()
            fmt.Println("nonce: ", nonce, "scan times: ", count)
            break
        }
        nonce += 1
    }
}

5.2.2 Rust

use sha256::digest;

fn main() {
    pow(String::from("0000"));
}

fn pow(diff: String) {
    println!("{}", diff);
    let mut count = 0;
    let mut nonce = 0;
    let base_str = String::from("fenix");
    loop {
        count += 1;
        let target_str = base_str.clone() + &nonce.to_string();
        let pow_hash = digest(target_str);
        print!("\r{}", pow_hash);
        if pow_hash.starts_with(&diff) {
            println!("");
            println!("nonce: {}, scan times: {}", nonce, count);
            break;
        }
        nonce += 1;
    }
}

When using mainstream programming languages ​​implement it, then tend to choose to use loop.

Elixir's variables are immutable, so conventional looping methods are not possible. Therefore we may use recursion to implement as follows:

defmodule Pow do
  def work(value, nonce, count, difficulty) do
    if String.starts_with?(value, difficulty) do
      IO.puts(value)
      IO.puts("nonce: #{nonce}, scan times: #{count}")
    else
      digest("#{value}#{nonce}") |> work(nonce + 1, count + 1, difficulty)
    end
  end

  def digest(value) do
    IO.write("\rhash: #{value}")

    :crypto.hash(:sha256, value)
    |> Base.encode16()
    |> String.downcase()
  end
end

{:module, Pow, <<70, 79, 82, 49, 0, 0, 10, ...>>, {:digest, 1}}

Pow.work("Fenix", 0, 0, "0000")
Pow.work("Fenix", 0, 0, "00000")

hash: a9d1ee2ad4586af4acc3b3dbd97d85355fbd4f8634a2062b38f4f878d350eb7e1770240000303ab87561a134d5ba70ff0dc96f59df2cb2c76a12418363a7065d7021e5
nonce: 177025, scan times: 177025
hash: 78ba29b80a1a9a0dbd363f00119a1822aad18cf999b93b732ff6fe7c42d4ee6b1468816000002fc5a2268fc4e118f4a221e1e76991c3f9a20d683f489e8466e26fcde54
nonce: 1468817, scan times: 1468817

:ok

The higher the difficulty, the more calculations are required.

0x06 Final State

Now, we'll add proof-of-work to the blockchain. The complete program is as follows:

defmodule Blockchain do
  defstruct chain: [], current_transactions: [], last_nonce: 0

  def new_block(c, name, nonce) do
    if valid_proof?(c.last_nonce, nonce) do
      b = %{
        :index => length(c.chain),
        :timestamp => NaiveDateTime.utc_now(),
        :name => name,
        :previous_hash => c |> last_block() |> hash(),
        :current_transactions => c.current_transactions
      }

      %{c | chain: c.chain ++ [b], current_transactions: [], last_nonce: nonce}
    else
      IO.puts("\nnonce: #{nonce} is invalid")
    end
  end

  def zero() do
    b = %{
      :index => 0,
      :timestamp => NaiveDateTime.utc_now(),
      :name => "ZERO",
      :previous_hash => "",
      :current_transactions => []
    }

    %Blockchain{
      chain: [b],
      current_transactions: [],
      last_nonce: 0
    }
  end

  def new_transaction(c, sender, recipient, amount) do
    tx = %{
      :sender => sender,
      :recipient => recipient,
      :amount => amount
    }

    %Blockchain{c | current_transactions: c.current_transactions ++ [tx]}
  end

  def last_block(c) do
    c.chain |> Enum.reverse() |> hd()
  end

  def hash(block) do
    value = block |> Poison.encode!()

    :crypto.hash(:sha256, value)
    |> Base.encode16()
    |> String.downcase()
  end

  def proof_of_work(last_nonce, nonce \\ 0) do
    case valid_proof?(last_nonce, nonce) do
      true ->
        nonce

      _ ->
        proof_of_work(last_nonce, nonce + 1)
    end
  end

  def valid_proof?(last_nonce, nonce, difficulty \\ "0000") do
    guess = "#{last_nonce}#{nonce}"

    guess_hash =
      :crypto.hash(:sha256, guess)
      |> Base.encode16()
      |> String.downcase()

    IO.write("\rdifficulty: #{difficulty}, attempt: #{nonce}, hash: #{guess_hash}")
    guess_hash |> String.starts_with?(difficulty)
  end
end

{:module, Blockchain, <<70, 79, 82, 49, 0, 0, 24, ...>>, {:valid_proof?, 3}}

Genesis Block

zero = Blockchain.zero()

%Blockchain{
  chain: [
    %{
      current_transactions: [],
      index: 0,
      name: "ZERO",
      previous_hash: "",
      timestamp: ~N[2022-04-01 12:27:28.717693]
    }
  ],
  current_transactions: [],
  last_nonce: 0
}

If you want to generate a new block, you must calculate the nonce and use the calculated nonce to create the block. If the nonce is not calculated, an error will be reported. For example, I randomly gave a nonce of 333 here and let's try to execute it:

first = zero |> Blockchain.new_block("first", 333)

difficulty: 0000, attempt: 333, hash: e73a36f8264731f64049b86564604e671d4bb1cfc0f6ab26803a5ad18040fee2
nonce: 333 is invalid

:ok

Call proof_of_work to compute the nonce:

nonce = Blockchain.proof_of_work(zero.last_nonce)

difficulty: 0000, attempt: 69732, hash: 0000e326186933fa83f0efd581d09409022ec07b73a10f549bbaa6472e8a1175

Use the calculated nonce to generate blocks:

first = zero |> Blockchain.new_block("first", nonce)

difficulty: 0000, attempt: 69732, hash: 0000e326186933fa83f0efd581d09409022ec07b73a10f549bbaa6472e8a1175

%Blockchain{
  chain: [
    %{
      current_transactions: [],
      index: 0,
      name: "ZERO",
      previous_hash: "",
      timestamp: ~N[2022-04-01 12:27:28.717693]
    },
    %{
      current_transactions: [],
      index: 1,
      name: "first",
      previous_hash: "d530c9090258905de8009fe933f8e4686916adc3e803b89600615a2fb817392d",
      timestamp: ~N[2022-04-01 12:28:33.450247]
    }
  ],
  current_transactions: [],
  last_nonce: 69732
}

Done!

Complete the following steps:

• Build the genesis block

• Calculate the nonce, create the first block

• Calculate new nonce

• Execute a few transactions to generate a new block

zero = Blockchain.zero()

nonce = Blockchain.proof_of_work(zero.last_nonce)
IO.inspect(nonce)
first = zero |> Blockchain.new_block("first", nonce)
IO.inspect(first)

nonce = Blockchain.proof_of_work(first.last_nonce)

second =
  first
  |> Blockchain.new_transaction("alice", "bob", 100)
  |> Blockchain.new_block("second", nonce)

IO.inspect(second)

difficulty: 0000, attempt: 69732, hash: 0000e326186933fa83f0efd581d09409022ec07b73a10f549bbaa6472e8a117569732
difficulty: 0000, attempt: 69732, hash: 0000e326186933fa83f0efd581d09409022ec07b73a10f549bbaa6472e8a1175%Blockchain{
  chain: [
    %{
      current_transactions: [],
      index: 0,
      name: "ZERO",
      previous_hash: "",
      timestamp: ~N[2022-04-01 12:29:06.201828]
    },
    %{
      current_transactions: [],
      index: 1,
      name: "first",
      previous_hash: "b8099550bfe6931ad0eccb7a18d1d638d33177fe6ecc7621dcb593bdc406cf00",
      timestamp: ~N[2022-04-01 12:29:06.916490]
    }
  ],
  current_transactions: [],
  last_nonce: 69732
}
difficulty: 0000, attempt: 23263, hash: 0000ffc4b3bdbd6d46a4649d48944700b204fe59883f915fe1030f05c16a5492%Blockchain{
  chain: [
    %{
      current_transactions: [],
      index: 0,
      name: "ZERO",
      previous_hash: "",
      timestamp: ~N[2022-04-01 12:29:06.201828]
    },
    %{
      current_transactions: [],
      index: 1,
      name: "first",
      previous_hash: "b8099550bfe6931ad0eccb7a18d1d638d33177fe6ecc7621dcb593bdc406cf00",
      timestamp: ~N[2022-04-01 12:29:06.916490]
    },
    %{
      current_transactions: [%{amount: 100, recipient: "bob", sender: "alice"}],
      index: 2,
      name: "second",
      previous_hash: "5e1e75f4822ac949e20944175a39d9301ad278611eb74043cb761ba83742df8c",
      timestamp: ~N[2022-04-01 12:29:07.222425]
    }
  ],
  current_transactions: [],
  last_nonce: 23263
}

%Blockchain{
  chain: [
    %{
      current_transactions: [],
      index: 0,
      name: "ZERO",
      previous_hash: "",
      timestamp: ~N[2022-04-01 12:29:06.201828]
    },
    %{
      current_transactions: [],
      index: 1,
      name: "first",
      previous_hash: "b8099550bfe6931ad0eccb7a18d1d638d33177fe6ecc7621dcb593bdc406cf00",
      timestamp: ~N[2022-04-01 12:29:06.916490]
    },
    %{
      current_transactions: [%{amount: 100, recipient: "bob", sender: "alice"}],
      index: 2,
      name: "second",
      previous_hash: "5e1e75f4822ac949e20944175a39d9301ad278611eb74043cb761ba83742df8c",
      timestamp: ~N[2022-04-01 12:29:07.222425]
    }
  ],
  current_transactions: [],
  last_nonce: 23263
}

0x07 The sage's time

Programming is about Data Transformation

Programming Should Be About Transforming Data.

If you deeply understand this quote, the ETL (Extract - Transform - Load) of data analysis is so natural, and Map/Reduce the dividing & conquering is also well understood.

There is no single correct way to write code, so we may change the way of thinking:

• Object-orientated programming is not the only way to design code

• Functional programming does not have to be complex and purely mathematical

• Programming is not based on assignments, if statements and loops

• Concurrency doesn't necessarily require locks, semaphores, monitors, etc.

• Processes don't have to consume a lot of resources

• Metaprogramming is not just an add-on to languages

• Even if programming is your job, it should be fun

Mastering Elixir may not yet add luster to your resume, allowing you to get a higher premium in the workplace. But learning Elixir can give you a different perspective on functions, mutability, concurrency, and high availability.

Elixir is very different from mainstream programming languages, and it will enrich your perspective and open your eyes to new programming thinking.

Finally, Why Elixir & Blockchain? Make sure Web3 happens in Elixir!

Reference

• Create a Pow Blockchain with Python

  • Reading：https://r8jmm3f9xe.feishu.cn/docs/doccnJ78y2G5KEXHObTnkpCrHwh

  • Video：https://ke.qq.com/course/3616174?tuin=d34bd514&taid=12533264329158062

• UTXO and model with account balance

• Geek Time: Explaining the Blockchain

• elixir：A panacea? or just have a name

Authors: ken, msfew, Snowyaya

Token Vendor is a vending machine that's combined of scaffold-eth and BuidlGuidl. This tutorial will walk you through how the project is implemented. To do that, we split the entire project to five smaller parts and it's verrifiable whether each part functions successfully after it's implemented.

0x01 Installation and Local Configuration

Step1. Open the terminal window and clone scaffold-eth base code

git clone https://github.com/scaffold-eth/scaffold-eth-typescript-challenges.git challenge-2-token-vendor

cd challenge-2-token-vendor

git checkout challenge-2-token-vendor

Step2. Install dependencies

Step3. Prepare the enviroment We need three terminal windows for this step, and each will execute their own command consecutively. The three commands will be used to:

yarn chain (start the `hardhat` backend and local nodes)

yarn deploy (compile, deploy the smart contract and push to the front-ended project reference)

yarn start (React front-ended App)

After commands executed

0x02 Prepare MetaMask Account

Change the DEBUG statement in packages/hardhat-ts/hardhat.config.ts to const DEBUG = true;; When viewing the account information, the private key of the wallet will aso be displayed, which can be imported to MetaMask.

Configure MetaMask: If you do not have MetaMask local network, configure by doing so:

• network name: Localhost 8545

• new RPC URL: http://localhost:8545

• chain ID: 31337

• currency symbol： ETH

Remember to check the value of chain ID. It should be 1337 normally, but for hardhat, it is 31337. If it's not changed, you might end up having this issue, which couldn't send transactions.

0x03 Launch your own token

3.1 Token smart contract

The Token in Ethereum is actually smart contract. The location of the contract file we need to customize is: packages/hardhat-ts/contracts/YourToken.sol.

pragma solidity >=0.8.0 <0.9.0;
// SPDX-License-Identifier: MIT

// inherited from OpenZeppelin's ERC20 Token standard
import '@openzeppelin/contracts/token/ERC20/ERC20.sol';

// learn more: https://docs.openzeppelin.com/contracts/3.x/erc20

contract YourToken is ERC20 {
  // ToDo: add constructor and mint tokens for deployer,
  //       you can use the above import for ERC20.sol. Read the docs ^^^

  // constructor
  constructor() public ERC20('Gold', 'GLD') {
    // _mint() 1000 * 10 ** 18 to msg.sender
    _mint(msg.sender, 1000 * 10**18);
  }
}

By inheriting the ERC20 standard (is ERC20), this Token has basic functions such as basic transfer, querying the balance of the Token held by the account. We only need to name the Token and specify its initial total amount to use.

• token symbol: GLD

• token name: Gold

• initial amount: 1000 * 10**18 (1000 Token)

10**18 means 10 to the 18th degree, where there are 18 zeroes. Why use such a large number, 1000000000000000000, to represent a Token? The reason is the same as we use penny in calculating dollar. The language EVM and Solidity can only handle integers, so in order to facilitate the Token to be cut into small units for circulation, we need a smaller unit, and the inherited ERC20 defines the length of this decimal place to be 18.

3.2 Deploy and transfer Token

After the contract is written, change the statement in packages/hardhat-ts/deploy/00_deploy_your_token.ts, fill in the prepared account, and test whether the transfer can be done successfully:

  // Todo: transfer tokens to frontend address
  const result = await yourToken.transfer(
    "0xC0802222dB0F31d63dc85d9C8CAa00485715A13c", ethers.utils.parseEther("1000"));

Note that if we want to transfer 1000 Token, we do not directly pass 1000 to the transfer function, but need to go through ethers.utils.parseEther to convert it into the number that is handleable by the contract.

After modification, deploy by command yarn deploy --reset.

If deployed successfully, call the balanceOf function through the Debug page in the browser to check whether the address after the transfer has the corresponding number of Tokens.

You can also try to transfer tokens from the current account to another account. However, before that, the wallet of the current account needs to have few ETH.

Press the button Grab funds from the faucet on the current page to get some.

Another way to get more ETH is through the faucet.paradigm.xyz page to authorize Twitter to log in and fill in the address to request.

Through the transfer function on the Debug page, we can transfer Token. The amount to be filled in needs to be converted. In the meantime, you can also click the Send button and modify it again in the confirmation box that pops up in MetaMask.

Note: Due to the contract changes or the time constraints, you may need to deploy multiple times and cannot complete the test at one time. Changes to the local network will cause the number of transactions in the account to be different from the number of transactions on MetaMask. When initiating a transaction, MetaMask is likely to alert you to the errors like Nonce too high. Expected nonce to be 0 but got x.. If so, you need to prepare a new account, or delete the account from MetaMask and try importing it again.

0x04 Build a vending machine Vendor

Now we start to implement the smart contract of the vending machine Vendor. It's framework is in the file packages/hardhat-ts/contracts/Vendor.sol.

4.1 Define the Token price

Token trading requires first determining the exchange rate between Token and ETH.

In the contract, we can define how many tokens an ETH can buy through the constant tokensPerEth. Remember that 1 Token means 1 * 10**18. Since the free ETH that the test account can get may be very few, this number may be set larger.

uint256 public constant tokensPerEth = 10000;

4.2 buyTokens function

The logic of buying Token is very simple. It is to calculate how many Tokens the sender of the transaction can get from the vending machine according to the amount of ETH in the transaction. The complete contract after implementing the buyTokens function is as follows:

pragma solidity >=0.8.0 <0.9.0;
// SPDX-License-Identifier: MIT

import '@openzeppelin/contracts/access/Ownable.sol';
import './YourToken.sol';

contract Vendor is Ownable {
  YourToken yourToken;

  uint256 public constant tokensPerEth = 10000;

  event BuyTokens(address buyer, uint256 amountOfEth, uint256 amountOfTokens);

  constructor(address tokenAddress) public {
    yourToken = YourToken(tokenAddress);
  }

  // ToDo: create a payable buyTokens() function:
  function buyTokens() public payable returns (uint256 tokenAmount) {
    require(msg.value > 0, 'ETH used to buy token must be greater than 0');

    uint256 tokenToBuy = msg.value * tokensPerEth;

    // check if the Vendor Contract has enough amount of tokens for the transaction
    uint256 vendorBalance = yourToken.balanceOf(address(this));
    require(vendorBalance >= tokenToBuy, 'Vendor has not enough tokens to sell');

    // Transfer token to the msg.sender
    bool success = yourToken.transfer(msg.sender, tokenToBuy);
    require(success, 'Failed to transfer token to user');

    emit BuyTokens(msg.sender, msg.value, tokenToBuy);

    return tokenToBuy;
  }
}

Key parts of the contract:

1. payable modifier:

   indicates that this function can receive ETH. It is necessary to mark this function as payable because buying Token requires transferring ETH to Vendor.

2. the statement require(msg.value > 0, 'ETH used to buy token must be greater than 0');

   constraint checking. Obviously, to buy Token, the amount of incoming ETH must be greater than 0. The value of msg.value is the amount of ETH.

3. address(this) function call:

   get the address of this contract

4. emit BuyTokens(msg.sender, msg.value, tokenToBuy)：

   trigger the BuyTokens event to record the address, cost, and purchase quantity of the purchased Token. Evens are available as EVM logging.

4.3 withdraw function

After the vending machine Vendor sells the Token, the buyer's ETH slowly accumulates into the Vendor account. So how do you get the ETH out of the contract? At this point we need to implement the withdraw function:

// ToDo: create a withdraw() function that lets the owner withdraw ETH
function withdraw() public onlyOwner {
  uint256 ethToWithdraw = address(this).balance;
  require(ethToWithdraw > 0, 'No ETH to withdraw');

  payable(msg.sender).transfer(ethToWithdraw);
}

Key parts of the contract:

1. onlyOwner midifier:

   Indicates that this function can only be called by the contract owner. This modifier is inherited from the Ownable.sol contract.

2. statement payable(msg.sender).transfer(ethToWithdraw):

   When calling the transfer function, the payable address must be used, not the ordinary address. So, you need to use payable() to convert instead of address() as in the previous sentence.

4.4 Deploy Vendor contract

withdraw function is ready. Who are allowed to withdraw funds from the contract? Of course the owner of the vendor, which is the owner of the vendor contract. The initial owner is the address that deploys the contract. If the address you connected with MetaMask is not the address for deployment, then you need to transfer the ownership to the address you use to log in the App.

Uncomment packages/hardhat-ts/deploy/01_deploy_vendor.ts's commented lines, then modify the Token amount transferring from YourToken to Vendor. If needed, assign new owner to Vendor contract.

// Todo: deploy the vendor

await deploy('Vendor', {
  // Learn more about args here: https://www.npmjs.com/package/hardhat-deploy#deploymentsdeploy
  from: deployer,
  args: [yourToken.address],
  log: true,
});

const vendor = await ethers.getContract("Vendor", deployer);

// Todo: transfer the tokens to the vendor
console.log("\n 🏵  Sending all 1000 tokens to the vendor...\n");

await yourToken.transfer(
  vendor.address,
  ethers.utils.parseEther("500") // Specify the amount of Token transferred to the Vendor.
);

// Assign new owner of Vendor contract
await vendor.transferOwnership("0xC0802222dB0F31d63dc85d9C8CAa00485715A13c");

Note: You also need to uncomment the lines that transfers Token to your address in packages/hardhat-ts/deploy/00_deploy_your_token.ts or make the value smaller, like modifying it into 500.

After the change, run yarn deploy --reset to deploy the contract again.

Below is the output for successful deployment:

Vendor will initially have 500 tokens, and I am going to buy 10 tokens.

It will need about 0.001 ETH.

After the purchase, Vendor will have 490 tokens left, and ETH balanced is increased by 0.001. We can also see the event for Buy Token:

Withdraw ETH (Now the account has 0.0089 ETH)

Withdraw successfully (Now the account has 0.0098 ETH)

0x05 Vendor buy back

Sometimes, we need to sell our Token and get ETH back. It will be great if Vendor can have this kind of operation.

Suppose here is the buy back steps:

1. Token owner takes out some of the Token, call YourToken's approve function with Vendor's contract address and Token amount, means user allows Vendor to sell this amount of Token.

2. Then, user can call Vendor contract's sellTokens function based on the approved amount, and get back ETH to user's address.

5.1 YourToken's approve function

This funciton does not need to be implemented in YourToken's contract since it is inherited from ERC20.sol. (Codes below do not need to be copied to YourToken contract)

• _approve is the main part of the logic. When user calls the method, spender will be the Vendor contract's address.

• 核心部分 _allowances[owner][spender] = amount; 负责在 YourToken 合约地址里面记录下用户允许 Vendor 获取的 Token 数量。

• The core is _allowances[owner][spender] = amount; that records in the YourToken's address the amount of users' Token amount that allows Vendor to get.

   function approve(address spender, uint256 amount) public virtual override returns (bool) {
      address owner = _msgSender();
      _approve(owner, spender, amount);
      return true;
  }
  
  function _approve(
      address owner,
      address spender,
      uint256 amount
  ) internal virtual {
      require(owner != address(0), "ERC20: approve from the zero address");
      require(spender != address(0), "ERC20: approve to the zero address");
  
      _allowances[owner][spender] = amount;
      emit Approval(owner, spender, amount);
  }
  

5.2 Vendor's sellTokens function:

Copy the SoldTokens event and sellTokens function into Vendor.sol:

```solidity
// ToDo: create a sellTokens() function:
event SoldTokens(uint256 amountOfEth, uint256 amountOfTokens);

function sellTokens(uint256 tokenToSell) public {
  require(tokenToSell > 0, 'You need to sell at least some tokens');

  // Calculate the needed ETH amount
  uint256 ethSold = tokenToSell / tokensPerEth;
  require(address(this).balance > ethSold, 'Not enough ETH to buy from Vendor');

  // Transfer Token from user to Vendor contract
  yourToken.transferFrom(msg.sender, address(this), tokenToSell);

  payable(msg.sender).transfer(ethSold);

  emit SoldTokens(ethSold, tokenToSell);
}

With the previous experience about `buyTokens`, we can easily understand `sellToken`. But the function of `yourToken.transferFrom` called within it needs to be looked at. `transferFrom`'s implementation in `ERC20.sol` is like that (you do not need to copy them into YourToken.sol or Vendor.sol):

function transferFrom(
    address from,
    address to,
    uint256 amount
) public virtual override returns (bool) {
    address spender = _msgSender();
    _spendAllowance(from, spender, amount);
    _transfer(from, to, amount);
    return true;
}

// check whether owner (Vendor contract) can get `msg.sender`'s needed amount of Token.
function _spendAllowance(
    address owner,
    address spender,
    uint256 amount
) internal virtual {
    uint256 currentAllowance = allowance(owner, spender);
    if (currentAllowance != type(uint256).max) {
        require(currentAllowance >= amount, "ERC20: insufficient allowance");
        unchecked {
            _approve(owner, spender, currentAllowance - amount);
        }
    }
}

function _transfer(
    address from,
    address to,
    uint256 amount
) internal virtual {
    require(from != address(0), "ERC20: transfer from the zero address");
    require(to != address(0), "ERC20: transfer to the zero address");

    _beforeTokenTransfer(from, to, amount);

    uint256 fromBalance = _balances[from];
    require(fromBalance >= amount, "ERC20: transfer amount exceeds balance");
    unchecked {
        _balances[from] = fromBalance - amount;
    }
    _balances[to] += amount;

    emit Transfer(from, to, amount);

    _afterTokenTransfer(from, to, amount);
}

Some key parts:

1. `internal` functions can only be called inside the contract or the child.
2. `virtual` functions means the method can be overwritten by the child.
3. ERC20 contract is to use a `_balances` mapping variable to store the amount of Token a address has. Transfer Token from one address to another, is to modify the value of the field in `_balances`.

   Let's see what sellTokens page works.

   Approve Vendor can sell this amount of Token:

   Sell Token to Vendor:

   Successfully with ETH (Now we have 0.0098 ETH)

## 0x06 Deploy contract to test networks

Now, `YourToken` and `Vendor`'s contracts are all done, and tested in the local test network. Now we can deploy the contract to the public testnet or mainnet.

File `packages/hardhat-ts/hardhat.config.ts`

```typescript
// const defaultNetwork = 'localhost';
const defaultNetwork = 'ropsten';

File packages/vite-app-ts/src/config/providersConfig.ts

// export const targetNetworkInfo: TNetworkInfo = NETWORKS.local;
export const targetNetworkInfo: TNetworkInfo = NETWORKS.ropsten;

After modifying the previous files, you can deploy the contract to Ropsten with yarn deploy (you need to have ETH on Ropsten network). The following error may be threwed when deploying:

deploying "Vendor"replacement fee too low (error={"name":"ProviderError","code":-32000,"_isProviderError":true}

This means the deployment operation is too fast, so that the transaction is sent too early and blocked. To solve this, you can seperate two deploy config files under packages/hardhat-ts/deploy into different folders.

Finally, run yarn build and yarn surge to build the front-end page, and deploy to Surge static file. Now we are all set!

Author: qiwihui

In this articles, we will show how to use Github pages to serve Voxel as HTML by using template. This HTML file will be used to mint our NFT.

In the previous article, we have upload the voxel file to Arweave with Permaweb Dropper. And we got the permanent link of the voxel file, for example https://5ywn6daenz6poefpjkgs3c2vdgtzsk2vevam6aozkfzzzwrmgi.arweave.net/nFF3J4VB0BP9eHt35gdffGuwCXaHfXwtJl2K6u4GyA0. Now Let's use Github pages to serve the voxel file as HTML.

0x01 Clone the repository

First, we can navigate to the WeLightProject/voxel-viewer-page project. This is a template repository. We will use this template to create our own project.

Click the use this template button, and you will see the following page. We need to fill the repository name and description. Then just click the Create repository from template button. Then the repository will be created in a few seconds.

0x02 Replace the voxel link and commit

Second, we need to clone the repository. We can click the "Clone" button. Then wen can copy the link of the repository. For example, https://github.com/qiwihui/MyDeerVoxel.git.

Then we can open a terminal and run the following command to clone the repository.

git clone https://github.com/qiwihui/MyDeerVoxel.git
cd MyDeerVoxel

We need to replace the voxel link in the handler.js file. We can open the handler.js file in your IDE, and in the 19th line, we need to replace the link in src tag to the permanent link of the voxel file, which is https://5ywn6daenz6poefpjkgs3c2vdgtzsk2vevam6aozkfzzzwrmgi.arweave.net/nFF3J4VB0BP9eHt35gdffGuwCXaHfXwtJl2K6u4GyA0.

Then we need to commit the changes and push it to Github. We can run the following command to commit the changes.

git add .
git commit -m "Add voxel file link"
git push origin master

0x03 Deploy to Github Pages

Finally, we need to setup the Github pages. We navigate to repository url and click Settings. Then we can click the Pages tab. We should choose the main branch. And then click Save.

The Github Pages will deploy your project automatically and you can see the website link when it is ready. For example, https://qiwihui.github.io/MyDeerVoxel.

We can now open the website in your browser. The website will show the voxel file.

Cool! Now we can mint our NFT using deployed url.

we need three items:

• Voxel URI -- Uploaded by Permaweb Dropper

  https://arweave.net/7izfDARufPcQr0qNLYtVGaeZK1UlQM8B_2VFznNosMs

• Github Pages URL -- You just generated

• Commit Hash -- to make sure the github pages is not changed after NFT minted.

Attention: All articles by NonceGeekLab do not constitute any investment advice.

PlayerLink:

A Trustless Decentralized Web3-Oriented Service Aggregation Protocol. Through reliable, secure, and scalable technology, PlayerLink empowers billions to create and get a new service experience.

NonceGeekLab:

Focus on Crypto, the most interesting track in the world!

https://github.com/WeLightProject/NonceGeekLab

Authors: msfew、leeduckgo、Erqi

0x00 Key questions

Good questions are the key for research

• Does Web3 need RSS?

• What kind of economic model will Web3's RSS have?

• What benefits can be given to users of Web3's RSS?

0x01 Area introduction

These are some objective analysis. The research is completed at January 2022, so some of the contents may not be updated.

1.1 Introduction

In the Web3 era, user data is open source, and developers can go to a public database like the blockchain for free and quick retrieval of data such as NFTs, footprints, DAO members, etc. owned by users.

Web2 social media, such as Twitter, are also actively embracing Web3 NFT artwork as a new way to interact and socialize. And in the context of high blockchain transaction fees and a more limited environment for smart contracts to operate, it is difficult for us to have a complete decentralized social application on Ethereum or other chains at this stage.

OpenSea only provides a personal space for NFT display, Twitter only provides a personal space for Web2 tweets, Mirror only provides a display of articles, and even no native subscription function. Because of this, developers started with feed streams and created aggregators for Web3 content, bringing each platform together in one place, bringing secondary interactions to the blockchain, and gradually exploring the possibilities of decentralized social.

In our article, we will focus on the following Web3 feed projects: RSS3, CyberConnect, Project Galaxy, and Showme.

1.2 Questions

For each project we can ask the following questions:

1. is the project sufficiently Web3 (decentralized, open source, open data)?

2. the existing ecosystem and progress of the project?

1.3 RSS3

"The feed of Web3"

Whitepaper

Let's know about RSS first before introducing RSS3.

1.3.1 RSS

RSS is an information aggregating protocol that unifies the format of information distribution and content synchronization. Users can subscribe to a website's RSS feed to receive content updates sorted by timeline, thus aggregating content from all websites.

RSS is characterized by openness and neutrality. In the Web2 era, RSS lost its appeal to the average user with the creation of centralized platforms. A centralized platform began to do evil in the "rodeo" of user data, leading to privacy violations, algorithmic abuses, and data monopolies.

1.3.2 RSS3 Introduction

RSS3 is an underlying indexing and syndication protocol that aggregates both Web2 and Web3 content on top of RSS, enabling efficient and centralized content distribution. It is also redundance-tolerant and fault-tolerant, under the control of the user.

The difference between RSS3 and traditional social media, such as Facebook, is that it gives users control of their feeds back to them. Users have the autonomy to decide what content they receive, rather than being "brainwashed" by a recommendation system.

The RSS3 team members have a strong belief in decentralization, and many of them have blogged about it. In addition, DIYgod, the developer of the well-known open source project RSSHub, is also on the RSS3 team, providing a strong endorsement of the indexing and syndication technology used by RSS3.

1.3.3 RSS3 Products

• rss3.bio（renamed to cheers.io in 2022/02）

rss3.bio is the first application of RSS3. rss3.bio is similar to QQ space in the Web3 era, showing a user's entire on-chain footprint, including NFT records, Gitcoin donation records, and Twitter and Mirror posting records. Users can get their own RNS with $PASS tokens to create personalized domains like leeduckgo.rss3.bio.

rss3.bio is a very small and compact Web3 personal business card that shows users' engagement with Web3 under one page. rss3.bio is relatively simple and currently only allows sharing business cards and following by domain name.

• revery.so

revery.so is a more complete application based on rss3.bio. revery.so provides full RSS3 feed aggregation, and each user can bring social connections from rss3.bio to revery.so to get their own feed stream.

1.3.4 RSS3 technical architecture

The technical implementation of RSS3 includes the implementation of the protocol and the implementation of the applications implemented using the protocol.

• RSS3 protocol

RSS3 protocol has interfaces and data structures for each address, and on-chain data such as personal information and NFT assets owned by the address are indexed to facilitate fast data acquisition and interface adaptation in the network.

Each of these addresses will have attributes such as id, profile avatar, personal link, etc.

• RSS3 network

Based on separate RSS3 files for each address, the entire data network parses the RSS3 files for each address and organizes the network of relationships, and finally indexes accounts that are said to be encrypted or non-encrypted, storing this data on a blockchain network. the blockchain network for RSS3 is overseen by a DAO as well as distributed nodes.

Users interact with the application and receive feed streams from RSS3's network, while the application interacts directly with the RSS3 network to submit user data that needs to be updated to the network.

• rss3.bio and revery.so

The source code of rss3.bio and revery.so are both in the RSS3 development group's GitHub account, and both are front-end applications that use the TypeScript language and the Vue or NextJS frameworks. The structure of the application is not complicated, in short, it consists of two main parts: taking data and styling it.

Since the RSS3 protocol has already organized the data very neatly, the front-end application can quickly build a Web3 social application with this same set of data. We can get the user data from the RSS3 network very easily and quickly by using a function like this.

async function getRecommendGroupMembers(type: string) {
  try {
    const res: RecommendationUsersResponse = (
      await axios.get('/recommendation/list', {
        baseURL: config.recommendations.endpoint,
        params: {
          type,
          limit: config.recommendations.userLimit,
        },
      })
    ).data;
    return <RSS3Index[]>res.response.filter((member) => member !== null); // What's wrong with you dude?
  } catch (e) {
    console.log(e);
  }
  return [];
}

Then, once you have the data, just render it in the page component:

    const getRecommendationGroups = async (type: string) => {
        setIsLoadingRecommendGroupMembers(true);
        const recommendGroupMemberIndexes = await RSS3.getRecommendGroupMembers(type);
...

It is very easy to develop social applications under the provisions of the open and neutral RSS3 protocol.

1.3.5 Answers

1. Is the project sufficiently Web3 (decentralized, open source, open data)?

RSS itself is a very neutral and open protocol, but in the current web culture, the survival space of RSS is getting smaller and smaller. RSS3 has been strengthened and reborn in the Web3 era, and as an open and unified protocol, RSS3 can help applications to get unified data very well, and will promote the development of the whole ecosystem as well as the ERC standard of Ethereumw.

For the decentralized property of RSS3, I think the team's concept and the architecture of the blockchain network are very good. However, I did not have access to specific information about the DAO architecture and nodes of the blockchain network. If this information can also be published, then it will reach the true decentralized network properties.

For open source, RSS3 members are active contributors on GitHub, and almost all projects are open source for developers to learn and view, which is something that is very much in the DNA of Web3.

For open data, I don't currently have access to developer documentation or an open interface to use. I think a better approach is to open up the data for developers to use and build applications first, rather than constructing applications by using the data first. Of course, in the future, when RSS3 develops its own projects that use its protocols to gain a foothold in Web3, RSS3 will certainly make the data public, which is a very good thing.

1. The current ecosystem and progress of the project?

Web3Pass, which went live in September 2021, currently(January 2022) has 35,000 individual pages. In January 2022, the official RSS3 white paper was released.

1.4 CyberConnect

"Connect everyone on Web3"

1.4.1 CyberConnect introduction

CyberConnect is also a content aggregation and indexing protocol. CyberConnect's mission is to build a social relationship graph infrastructure for Web3, returning ownership of social data to users while providing an infrastructure for all Web3 developers to integrate and build.

CyberConnect's emphasis is not only on aggregating data on the chain together, but more importantly, on empowering users with the Web3 social relationships through decentralized storage. It's as much about the on-chain interactions that the user has at their address as it is about the data they have that they can take with them through the Web3 world. For example, Twitter followers and followers can be brought directly into the CyberConnect application, and interactions in CyberConnect can be brought into other social applications.

CyberConnect believes that Web3 will be developer-driven, so what they are doing is aggregating and indexing decentralized social relationships, and then handing them off to different projects to be presented on the front end.

1.4.2 Cyberconnect projects

• Cyberconnect.me

Cyberconnect.me is similar to RSS3's two products in that it aggregates data and presents social connections on the chain.

Cyberconnect.me uses a recommendation engine to better recommend potential user interactions, which is more in line with most users' habits. It also provides the ability to comment on users' homepages, allowing secondary interactions to be truly reflected in the Web3 Feed product.

• CyberChat

CyberChat is a real-time communication application based on CyberConnect's social graphs and is still in development.

1.4.3 CyberConnect architecture

• CyberConnect Indexer

The open source code of this project is available at this repository. Indexer open-sources the method of aggregating and indexing data from various social networks. We can access the data we need through the contract addresses and APIs of each different platform:.

const (
    SuperrareContractAddress  = "0x41a322b28d0ff354040e2cbc676f0320d8c8850d"
    OpenSeaContractAddress    = "0x495f947276749ce646f68ac8c248420045cb7b5e"
    RaribleContractAddress    = "0xd07dc4262bcdbf85190c01c996b4c06a461d2430"
    FoundationContractAddress = "0x3b3ee1931dc30c1957379fac9aba94d1c48a5405"
    ZoraContractAddress       = "0xabefbc9fd2f806065b4f3c237d4b59d9a97bcac7"
    ContextContractAddress    = "ctx"
)

const (
    ContextUrl          = "https://context.app/api/profile/%s"
    SuperrareUrl        = "https://superrare.com/api/v2/user?address=%s"
    RaribleFollowingUrl = "https://api-mainnet.rarible.com/marketplace/api/v4/followings?owner=%s"
    RaribleFollowerUrl  = "https://api-mainnet.rarible.com/marketplace/api/v4/followers?user=%s"
)

func sendRequest(client *http.Client, args RequestArgs) ([]byte, error) {
    var req *http.Request
    var err error

    switch args.method {
    case "GET":
        req, err = http.NewRequest(args.method, args.url, nil)
        if err != nil {
            return nil, err
        }
        for k, v := range args.header {
            req.Header.Add(k, v)
        }
        query := req.URL.Query()
        for k, v := range args.params {
            query.Add(k, v)
        }
        req.URL.RawQuery = query.Encode()
...

Such an approach is more customizable and flexible than RSS3, but is not as out-of-the-box as RSS3 and may require manual deployment and debugging by the developer.

• CyberConnect packages

The source code for the CyberConnect npm library is available at this repository. This library provides CyberConnect classes that include functions for DID and interactive social graph data, encapsulating complex authentication logic into easy-to-use functions. Developers can use this library for social software development.

1.4.4 Answers

1. Is the project sufficiently Web3 (decentralized, open source, open data)?

CyberConnect is more of a developer-oriented project, and it opens up the interface to the ceramic network for developers to use faster than RSS3.

For decentralization, the Ceramic used by CyberConnect is a decentralized network that uses IPFS for storage.

For open source, the third-party libraries and indexer for the CyberConnect project are open source, but the rest of the client code is not.

For open data, CyberConnect has opened up its own data for developers to use.

1. What is the current ecosystem and progress of the project?

Currently Cyberconnect's client has 38w users, and the account with the most followers has more than 1w followers.

1.5 Project Galaxy

"Build better communities in Web3"

Project Galaxy is an NFT-as-a-service infrastructure platform that allows anyone to create, distribute, or gamify NFTs at will using custom on-chain data, developers to create custom loyalty programs, and individuals to distribute and subscribe to NFTs.

Project Galaxy is similar to OpenSea in that it aggregates various families of NFTs, features NFT showcases and follows users, and more. It also includes an aggregation page for activities such as AMA, which makes it more intuitive and easy to follow the trends and progress of each eco-community.

1.6 Showme

"A subscription NFT social network built on Web3"

Showme provides subscriptions to communities such as NFT to follow, allowing users to more closely engage and stay up to date with community trends. Whenever a user subscribes to a new community, a new NFT is Minted and used as an on-chain credential. At the same time, community credentials on different chains are separate from the communities themselves.

Showme's on-chain footprint index uses the protocol provided by RSS3 for crawling.

1.7 RSS3, CyberConnect, Project Galaxy, Showme

Both RSS3 and CyberConnect are protocols for capturing on-chain and off-chain data to do so, bridging the silos of data across Web3's blockchain networks. They form a social data network that belongs entirely to users and uses decentralized storage that can be used by different projects.

CyberConnect is more advanced than RSS3 and is more Web2 social, with personal page likes and soon a live chat feature.

The other difference is that RSS3 has RSS as its main component, which means that RSS3 has a natural contradiction with the recommendation system and the list of recommended followers on revery.so is randomly generated; Cyberconnect is more flexible and uses a recommendation system to better capture users' possible preferences and anticipate their next actions.

NFT is an important part of social in the Web3 era, and Project Galaxy and Showme focus on cultivating NFT communities, with Project Galaxy working closely with Cyberconnect and Showme working closely with RSS3. Project Galaxy focuses on community activities such as AMA of service projects, while Showme focuses on spontaneous communication and announcement of service communities.

0x02 NonceGeek views

This chapter describes the subjective view of NonceGeek.

RSS is a web feed that allows users and applications to access updates to websites in a standardized, computer-readable format. Subscribing to RSS feeds can allow a user to keep track of many different websites in a single news aggregator, which constantly monitor sites for new content, removing the need for the user to manually check them. News aggregators (or "RSS readers") can be built into a browser, installed on a desktop computer, or installed on a mobile device.

-- Wikipedia

RSS originated in the early days of the Internet era, before the existence of giant whales of apps like today (Facebook, Twitter, Google, Tencent, TikTok......). People used RSS to parse their favorite feeds.

With the development of the Internet, various App whales have emerged, and we just need to register an account, and the App will feed us information. We no longer need to customize our own feeds. App will "continuously push" based on our browsing preferences...... So, RSS is gradually being eliminated by history.

This is certainly an inevitable process.

However, there are some interesting questions to ponder. Is this inevitable process the "right" one, and is RSS likely to be revived? And if so, what will the new generation of RSS look like?

2.1 The "humane" and "right"

Too often, we believe that "survival of the fittest" means that those who survive are naturally right.

However, this crude judgment is problematic. Very often, what survives is "in line with human nature", not "right".

For example, if we think "healthy food = right, unhealthy food = wrong". The reason why fast food has survived so well in the world is not because it is right, but because it responds to human nature.

Similarly, why is it that "recommendation algorithm-based apps" are alive and well, but RSS is dying out?

I think it's because...

The App based on recommendation algorithm is in line with human nature, but it doesn't make it right.

As the old saying goes, "good advice often jars on the ear," and saying nice things is human nature and will be liked naturally.

Likewise, recommending content based on your existing preferences is human nature and will be naturally liked.

However, just as being addicted to fast food can make us less and less healthy, being caught up in recommendation algorithms can affect our "mental health" as well.

We can draw a simple model to describe it.

Suppose initially I show "Preference A" and "Preference B" in the App (e.g. TikTok), then the App will keep recommending me content of "Preference A" and "Preference B", thus reinforcing my preference for "Preference A" and "Preference B", and then the cycle continues......

It's naturally in the App's interest for users to get caught up in their existing preferences - because they stick to the App.

But is it really in the user's interest?

I was addicted to soap operas for a while, so my timeline was full of soap operas. Then suddenly one day I broke away. I wanted to cut ties with soap operas, but the app still pushed soap operas based on my preferences.

This is the essence of the recommendation algorithm - "to keep strengthening your existing preferences, creating stickiness to your existing preferences, which in turn becomes stickiness to the App".

We can see that its essence is closed and not open at the spiritual level. After a long period of time under the system of "recommendation algorithm", we will eventually come to a state - we no longer make changes to our preferences, but the existing preferences keep increasing.

Even if we link the Internet, we will still become one closed system after another.

The opposite is RSS, which is absolutely anti-human, requiring you to get your own subscription feeds and then manage them manually on your own - similar to how we go about making complicated dishes at home.

However, this sacrifice is rewarded with an open and comfortable information system!

As shown above, in the RSS-based system, we have Preference A and Preference B. We are free to control the "traffic" of each preference, let's say 100 messages per day for "Preference A" and 50 messages per day for "Preference B". I used to like "fishing" and subscribed to a lot of "fishing" related feeds, but now I don't like it anymore, Ok, cut all the related "feeds"!

TimeLine is instantly clean.

Therefore, this system is "open", and people who use this system will also have "high openness".

Openness is the essential spirit of the Internet, isn't it?

2.2 Is it possible for RSS to be revived?

The road to RSS revival may be a tortuous one, but in the long run RSS will regain a larger market.

But one key factor is that there are "incentives" to offset the "costs of hassle" associated with RSS use, depending on the design. We can divide the incentives into "economic incentives" and "non-economic incentives".

• Economic Incentives

  There is a financial incentive for providing a good RSS feed, which may be created by the provider or integrated by the provider.

• Non-financial Incentives

  For example, reputation in the Crypto world, etc.

2.3 What does a Base on Blockchain/Web3 RSS look like?

The following is purely a personal opinion.

2.3.1 The redefined personal blog

A personal blog is a blog with its own domain name that is not dependent on any blogging platform.

Although personal blogs have declined in China (only some of the tech leads are still running and maintaining blogs), there are still many personal bloggers from a global perspective.

In the Crypto world, we can redefine blogging, which is supposed to be an important source of information for RSS. So it seems we should talk about a "blogging renaissance" before a RSS renaissance? But that's another topic.

Here's a brief list of possible ways Crypto blogs could play out.

• The Crypto identity of the blogger can be seen

• The ability to aggregate the blogger's NFTs

• Can aggregate the blogger's multiple Web3 dApp content, such as Mirror

• If the blogger is a technical blogger, it can show the Web3 projects the blogger is involved in

• There can be a gateway to the Crypto World/Metaverse where the blogger resides

• Finally, of course, the blogger can provide RSS feeds

2.3.2 Penetrating revenue and traceable re-creation

This is different from the Web2 RSS system. Because it's based on blockchain, the new generation of RSS is technically "revenue-penetrating" and "re-creation-traceable".

In other words, through smart contracts, the creators and distributors of RSS feeds, original works and re-creations can both receive revenue, so that the new generation of RSS can really carry "tangible value" and thus offset the "cost of trouble" brought about by the use of RSS.

However, the proposition of blockchain empowering creators has been mentioned for years, but we have not seen any particularly successful product. Is this because the previous products were not designed from the perspective of "RSS revival"? This requires further thought and discussion.

0x03 Secondary development practice

Performing secondary development practices is a mean to gain a deeper understanding of the product.

3.1 RSS3 architecture

Pics Got From: https://twitter.com/diygod/status/1492462952322109444?s=21

3.2 Development ideas

Because the RSS3 data are publicly available:

https://github.com/NaturalSelectionLabs/RSS3-Network-Data

So it is easy to implement RSS3-based projects through the SDK or directly through the API interface. Here, we implement an example of an on-chain resume incorporating Markdown documents in rss3.bio (now renamed cheers.bio);

https://erqi.github.io/Web3Pass/#/

The source code is available at;

https://github.com/ErQi/Web3Pass/tree/resume

3.3 Practices

The Footprint area of the original project was removed and filled with Content. Then a custom Markdown component was introduced to complement the Content area.

3.3.1 Add Markdown.vue

This component group is to be used to load the content display of Markdown.

Loading mechanism

    Get markdown content -> Process into markdown html format -> Render by introducing markdown style file

3.3.2 Get markdown content

Here we have two forms of fetching. We get it from local files and github api respectively.

Local loading method

To load locally, you need webpack to recognize the md file, and you need to configure the corresponding loader. Add the html-loader package dependency via npm, and then configure the corresponding loader in the rules section of the webpack.config.js configuration file.

            {
                test: /\.md$/,
                use: [
                    {
                        loader: 'html-loader',
                    },
                ],
            },

Once configured, you can import the local md file via import to get the corresponding content. To load locally, you need to modify the v-html attribute of the article tag in Markdown.vue.

import md from '@/assets/RSS3源码分析.md';

...

    <article className="markdown-body" v-html="compiledMarkdown"></article>

Create your own GitHub repository quickly

Network loading method

The network load uses the github api to get the content of the file in the corresponding path. The use of the api is not described in detail. The normal content is base64 encoded. So we add a base64 file to decode it.

        axios.get(config.mdUrl).then((response) => {
            this.mdText = response.data.content;
            this.mdText = BASE64Util.base64_decode(this.mdText);
            this.mdText = marked(this.mdText || '', {
                sanitize: true,
            });
            console.log(this.mdText);
        });

Also, the v-html attribute of the article tag in Markdown.vue uses the parsed mdText attribute directly.

    <article className="markdown-body" v-html="mdText"></article>

The default load file path is configured in the /mdUrl property of the /src/config.ts file.

// The standard format is as follows.
https://api.github.com/repos/WeLightProject/WeLightBlockchainOS/contents/README.md?ref=main
// https://api.github.com/repos/{organization/username}/{projectname}/contents/{folderpath,name}?ref={branchname}

Processing to html format

The markdown content into html format requires the marked library, which can be imported and used after adding the dependencies via npm. Baidu's import is without brackets, but here without brackets it will report an error, the reason is unknown, I also saw this import method in other files, so I tried to add brackets, only to solve the problem that has been reported as unable to import.

After importing the original md content directly as parameters passed in, the return is the content of the html format

import { marked } from 'marked';

            .....

            marked(md || '', {
                sanitize: true,
            })

Introduce css style rendering

Introduce the markdown-it-vue dependency via npm, and then import the following style.

import 'markdown-it-vue/dist/markdown-it-vue.css';

I wanted to use a third-party component to display vue directly in one step, but after I introduced it, I got all kinds of errors. The reason is unknown. I suspect it's because the current vue version is 5.x. Because in the markdown-it-vue issue, I saw that vue 5.x version was reporting errors when importing. The error message is not the same though. I've tried all the other markdown rendering and editing components, but it's just a mess of errors. It doesn't work properly.

So finally I had to go for introduce basic content->convert html format->css style rendering basic processing to handle it.

3.3.3 Fixed home page's access address

In the original project, the wallet address is used to capture user data and then visit the home page of the wallet user. In the case of on-chain resume, this step is not needed and the page of the fixed user is displayed directly.

Tried to locate the home page directly through the route and splice the user to get the data, and found that it did not work well.

The final solution was a bit of a detour, redirecting directly to the home page inside the home page.

Need to display a user data directly modify address in src/config.ts can be.

3.3.4 Deployment

After downloading the project, modify the wallet address in src/config.ts and the corresponding md file url address to suit your needs.

export default {
    address: '0xC994B5384C0d0611De2ecE7d6fF1aD16C34A812F',
    mdUrl: 'https://api.github.com/repos/komomoo/vuepress-theme-resume/contents/example/README.md?ref=master',
    ...
}

Then use the webpack command to package, the package can be accessed normally (packaging time is long, no progress bar, you need to wait patiently, about 1 minute or so).

国内用户如需交流，可加微信：197626581.

Authors: qiwihui, msfew

History Articles List:

• Quickstart | Web3.0 dApp Dev 0x01

• Web3.0 dApp Developer Growth Path | Web3.0 dApp Dev 0x02

• Scaffold-Eth Quickstart | Web3.0 dApp Dev 0x03

• Get & Set Value 1.0 | Web3.0 dApp Dev 0x04

• Get & Set Value 2.0 | Web3.0 dApp Dev 0x05

• Get & Set Value 3.0 | Web3.0 dApp Dev 0x06

loogies-svg-nft is a simple NFT minting and displaying project provided by scaffold-eth. In this tutorial, we will walk you through a step-by-step analysis and implementation of this project.

Since the loogies-svg-nft branch and the master branch of the project have some differences in the component library and home page, the master branch code needs to be merged with the loogies-svg-nft branch to resolve the conflicts and get a brand new set of code based on the new component library. You can see the loogies-svg-nft branch of the project at https://github.com/qiwihui/scaffold-eth.git. The following part of this article will be based on these codes for deployment and analysis.

0x01 Running and testing locally

First let's run the project to see what we are going to analyze and implement.

Running locally

First we run the project locally.

1. clone the project and switch to the loogies-svg-nft branch:

   git clone https://github.com/qiwihui/scaffold-eth.git loogies-svg-nft
   cd loogies-svg-nft
   git checkout loogies-svg-nft
   

2. install dependencies

3. start the front end server

   yarn start
   

4. run the local test network in a second terminal window

5. deploy contract in a third terminal window

6. go to http://localhost:3000 in browser to see the app

Testing locally

1. First add the local network to the MetaMask wallet and switch to the local network;

   • Network name: Localhost 8545

   • Add RPC URL: http://localhost:8545

   • Chain ID: 31337

   • Currency Symbol: ETH

2. Create a new local wallet address;

3. Copy the wallet address and send some test ETH to this address in the bottom left corner of the page;

4. Click on connect in the top right corner of the page to connect to the wallet;

5. Click on Mint button to mint;

6. When the transaction succeed, you can see the newly minted NFT.

Now we begin our analysis of the project contract.

0x02 Loogies Contract Analysis

NFT and ERC721

NFT (Non-Fungible Token), refers to non-homogenized tokens, corresponding to the ERC-721 standard on Ethereum. Generally in smart contracts, the definition of NFT contains tokenId and tokenURI, tokenId is unique ID for each NFT, and tokenURI for the metadata of the NFT is saved, which can be image URL, description, attributes, etc. If an NFT wants to display and sell in the NFT marketplace, the tokenURI content needs to correspond to the standards of the NFT marketplace. For example, in the NFT marketplace OpenSea's metadata standards, it is indicate attributes that need to be set for NFT display.

NFT metadata and presentation's connection in OpenSea

Contract overview

loogies-svg-nft project's contract code is at ' packages/hardhat/contracts/, and contains three files.

packages/hardhat/contracts/
├── HexStrings.sol
├── ToColor.sol
└── YourCollectible.sol

• HexString.sol: generate address string;

• ToColor.sol: generate color value string;

• YourCollectible.sol： Loogies NFT's contract file with functions of minting and metadata generating.

Contract architecture and methods:

contract YourCollectible is ERC721, Ownable {

    // Constructor function
  constructor() public ERC721("Loogies", "LOOG") {
  }
  // Mint NFT
  function mintItem()
      public
      returns (uint256)
  {
    ...
  }
    // Get tokenURI from tokenId
  function tokenURI(uint256 id) public view override returns (string memory) {
    ...
  }
    // Generate SVG from tokenId
  function generateSVGofTokenById(uint256 id) internal view returns (string memory) {
    ...
  }

    // Render tokenId's svg code for graphics display
  function renderTokenById(uint256 id) public view returns (string memory) {
    ...
  }

}

Constructor function

constructor() public ERC721("Loogies", "LOOG") {
    // RELEASE THE LOOGIES!
  }

Token name: Loogies

Token symbol: LOOG

The contract is inherited from OpenZeppelin's ERC721.sol, which is the basic contract code provided by OpenZeppelin and can be easily used by developers.

Library functions

Contract applies different library functions for uint256, uint160 and bytes3 to extend features:

// let uint256 have toHexString
using Strings for uint256;
// let uint160 have configurable toHexString
using HexStrings for uint160;
// let bytes3 have easy color representation
using ToColor for bytes3;
// counter feature
using Counters for Counters.Counter;

Mint time limit

The following code is for Mint time limit:

uint256 mintDeadline = block.timestamp + 24 hours;

function mintItem()
      public
      returns (uint256)
  {
      require( block.timestamp < mintDeadline, "DONE MINTING");
...

Contracts is mintable within 24 hours of deployment, and beyond that time an exception is raised. This mechanism is similar to pre-sales. Since this contract is relatively simple, no whitelist mechanism is used, and generally in practice, pre-sales and whitelists are used to control the NFTs issuing.

Mint NFT

Minting NFT is to set two variables in contract:

• tokenId with owner

• tokenId with tokenURI

Let's look at the minting function mintItem:

// Store each Loogies' attribute
mapping (uint256 => bytes3) public color;
mapping (uint256 => uint256) public chubbiness;

...

function mintItem()
      public
      returns (uint256)
  {
      require( block.timestamp < mintDeadline, "DONE MINTING");
            // Self increment for _tokenIds to make sure _tokenIds is non-fungiable
      _tokenIds.increment();

      uint256 id = _tokenIds.current();
            // Binder minter and tokenId
      _mint(msg.sender, id);
            // Randomly generate tokenId's attributes
      bytes32 predictableRandom = keccak256(abi.encodePacked( blockhash(block.number-1), msg.sender, address(this), id ));
      color[id] = bytes2(predictableRandom[0]) | ( bytes2(predictableRandom[1]) >> 8 ) | ( bytes3(predictableRandom[2]) >> 16 );
      chubbiness[id] = 35+((55*uint256(uint8(predictableRandom[3])))/255);

      return id;
  }

Also:

• tokenId self increments when minting to make sure each tokenId is only one;

• _mint function binds tokenId with owner;

• Each tokenId's attribute is generated randomly:

  • By pre-block's hash (blockhash(block.number-1)), msg.sender, contract address (address(this)) and tokenId's generated hash predictableRandom;

  • Calculate NFT color: doing bit operations to predictableRandom's first three bits to get the color, color is represented by bytes3. bytes2(predictableRandom[0]) is the lowest blue value, ( bytes2(predictableRandom[1]) >> 8 ) is the green value, ( bytes3(predictableRandom[2]) >> 16 ) is the red value;

  • Calculate NFT chubbiness: 35+((55*uint256(uint8(predictableRandom[3])))/255); ，uint8(predictableRandom[3]) is between 0~255, so the minimum is 35, and the maximum is 35 + 55 = 90.

For example: When color is 0x4cc4c1, chubbiness is 88, the NFT picture is:

tokenURI function

Function tokenURI takes tokenId parameter, returns encoded metadata string:

function tokenURI(uint256 id) public view override returns (string memory) {
            // check id if exist
      require(_exists(id), "not exist");
      string memory name = string(abi.encodePacked('Loogie #',id.toString()));
      string memory description = string(abi.encodePacked('This Loogie is the color #',color[id].toColor(),' with a chubbiness of ',uint2str(chubbiness[id]),'!!!'));
      // generate svg base64 for image
            string memory image = Base64.encode(bytes(generateSVGofTokenById(id)));

      return
          string(
              abi.encodePacked(
                'data:application/json;base64,',
                                // encode metadata with base64
                Base64.encode(
                    bytes(
                          abi.encodePacked(
                              '{"name":"',
                              name,
                              '", "description":"',
                              description,
                              '", "external_url":"https://burnyboys.com/token/',
                              id.toString(),
                              '", "attributes": [{"trait_type": "color", "value": "#',
                              color[id].toColor(),
                              '"},{"trait_type": "chubbiness", "value": ',
                              uint2str(chubbiness[id]),
                              '}], "owner":"',
                              (uint160(ownerOf(id))).toHexString(20),
                              '", "image": "',
                              'data:image/svg+xml;base64,',
                              image,
                              '"}'
                          )
                        )
                    )
              )
          );
  }
// Generated SVG string
function generateSVGofTokenById(uint256 id) internal view returns (string memory) {
...
}

// Render image
// Visibility is `public` to enable it being called by other contracts for composition.
function renderTokenById(uint256 id) public view returns (string memory) {
...
}

In this, generateSVGofTokenById function returns tokenId's SVG string on its color and chubbiness, renderTokenById renders the token.

We see that the NFT needs to include:

• name

• description

• external_url

• attributes

  • color

  • chubbiness

  • owner

  • image

We can get to know more about SVG by an example.When tokenId is 1, the tokenURI is:

data:application/json;base64,eyJuYW1lIjoiTG9vZ2llICMxIiwiZGVzY3JpcHRpb24iOiJUaGlzIExvb2dpZSBpcyB0aGUgY29sb3IgIzRjYzRjMSB3aXRoIGEgY2h1YmJpbmVzcyBvZiA4OCEhISIsImV4dGVybmFsX3VybCI6Imh0dHBzOi8vYnVybnlib3lzLmNvbS90b2tlbi8xIiwiYXR0cmlidXRlcyI6W3sidHJhaXRfdHlwZSI6ImNvbG9yIiwidmFsdWUiOiIjNGNjNGMxIn0seyJ0cmFpdF90eXBlIjoiY2h1YmJpbmVzcyIsInZhbHVlIjo4OH1dLCJvd25lciI6IjB4MTY5ODQxYWEzMDI0Y2ZhNTcwMDI0ZWI3ZGQ2YmY1Zjc3NDA5MjA4OCIsImltYWdlIjoiZGF0YTppbWFnZS9zdmcreG1sO2Jhc2U2NCxQSE4yWnlCM2FXUjBhRDBpTkRBd0lpQm9aV2xuYUhROUlqUXdNQ0lnZUcxc2JuTTlJbWgwZEhBNkx5OTNkM2N1ZHpNdWIzSm5Mekl3TURBdmMzWm5JajQ4WnlCcFpEMGlaWGxsTVNJK1BHVnNiR2x3YzJVZ2MzUnliMnRsTFhkcFpIUm9QU0l6SWlCeWVUMGlNamt1TlNJZ2NuZzlJakk1TGpVaUlHbGtQU0p6ZG1kZk1TSWdZM2s5SWpFMU5DNDFJaUJqZUQwaU1UZ3hMalVpSUhOMGNtOXJaVDBpSXpBd01DSWdabWxzYkQwaUkyWm1aaUl2UGp4bGJHeHBjSE5sSUhKNVBTSXpMalVpSUhKNFBTSXlMalVpSUdsa1BTSnpkbWRmTXlJZ1kzazlJakUxTkM0MUlpQmplRDBpTVRjekxqVWlJSE4wY205clpTMTNhV1IwYUQwaU15SWdjM1J5YjJ0bFBTSWpNREF3SWlCbWFXeHNQU0lqTURBd01EQXdJaTgrUEM5blBqeG5JR2xrUFNKb1pXRmtJajQ4Wld4c2FYQnpaU0JtYVd4c1BTSWpOR05qTkdNeElpQnpkSEp2YTJVdGQybGtkR2c5SWpNaUlHTjRQU0l5TURRdU5TSWdZM2s5SWpJeE1TNDRNREEyTlNJZ2FXUTlJbk4yWjE4MUlpQnllRDBpT0RnaUlISjVQU0kxTVM0NE1EQTJOU0lnYzNSeWIydGxQU0lqTURBd0lpOCtQQzluUGp4bklHbGtQU0psZVdVeUlqNDhaV3hzYVhCelpTQnpkSEp2YTJVdGQybGtkR2c5SWpNaUlISjVQU0l5T1M0MUlpQnllRDBpTWprdU5TSWdhV1E5SW5OMloxOHlJaUJqZVQwaU1UWTRMalVpSUdONFBTSXlNRGt1TlNJZ2MzUnliMnRsUFNJak1EQXdJaUJtYVd4c1BTSWpabVptSWk4K1BHVnNiR2x3YzJVZ2NuazlJak11TlNJZ2NuZzlJak1pSUdsa1BTSnpkbWRmTkNJZ1kzazlJakUyT1M0MUlpQmplRDBpTWpBNElpQnpkSEp2YTJVdGQybGtkR2c5SWpNaUlHWnBiR3c5SWlNd01EQXdNREFpSUhOMGNtOXJaVDBpSXpBd01DSXZQand2Wno0OEwzTjJaejQ9In0=

Decode data:application/json;base64, with base64. Then the string can generate the following json (simplified version):

{
  "name": "Loogie #1",
  "description": "This Loogie is the color #4cc4c1 with a chubbiness of 88!!!",
  "external_url": "https://burnyboys.com/token/1",
  "attributes": [
    {
      "trait_type": "color",
      "value": "#4cc4c1"
    },
    {
      "trait_type": "chubbiness",
      "value": 88
    }
  ],
  "owner": "0x169841aa3024cfa570024eb7dd6bf5f774092088",
  "image": "data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iNDAwIiBoZWlnaHQ9IjQwMCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48ZyBpZD0iZXllMSI+PGVsbGlwc2Ugc3Ryb2tlLXdpZHRoPSIzIiByeT0iMjkuNSIgcng9IjI5LjUiIGlkPSJzdmdfMSIgY3k9IjE1NC41IiBjeD0iMTgxLjUiIHN0cm9rZT0iIzAwMCIgZmlsbD0iI2ZmZiIvPjxlbGxpcHNlIHJ5PSIzLjUiIHJ4PSIyLjUiIGlkPSJzdmdfMyIgY3k9IjE1NC41IiBjeD0iMTczLjUiIHN0cm9rZS13aWR0aD0iMyIgc3Ryb2tlPSIjMDAwIiBmaWxsPSIjMDAwMDAwIi8+PC9nPjxnIGlkPSJoZWFkIj48ZWxsaXBzZSBmaWxsPSIjNGNjNGMxIiBzdHJva2Utd2lkdGg9IjMiIGN4PSIyMDQuNSIgY3k9IjIxMS44MDA2NSIgaWQ9InN2Z181IiByeD0iODgiIHJ5PSI1MS44MDA2NSIgc3Ryb2tlPSIjMDAwIi8+PC9nPjxnIGlkPSJleWUyIj48ZWxsaXBzZSBzdHJva2Utd2lkdGg9IjMiIHJ5PSIyOS41IiByeD0iMjkuNSIgaWQ9InN2Z18yIiBjeT0iMTY4LjUiIGN4PSIyMDkuNSIgc3Ryb2tlPSIjMDAwIiBmaWxsPSIjZmZmIi8+PGVsbGlwc2Ugcnk9IjMuNSIgcng9IjMiIGlkPSJzdmdfNCIgY3k9IjE2OS41IiBjeD0iMjA4IiBzdHJva2Utd2lkdGg9IjMiIGZpbGw9IiMwMDAwMDAiIHN0cm9rZT0iIzAwMCIvPjwvZz48L3N2Zz4="
}

We decode image value and format it to get image SVG:

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" width="400" height="400">
   <g id="eye1">
      <ellipse stroke-width="3" ry="29.5" rx="29.5" id="svg_1" cy="154.5" cx="181.5" stroke="#000" fill="#fff" />
      <ellipse ry="3.5" rx="2.5" id="svg_3" cy="154.5" cx="173.5" stroke-width="3" stroke="#000" fill="#000000" />
   </g>
   <g id="head">
      <ellipse fill="#4cc4c1" stroke-width="3" cx="204.5" cy="211.80065" id="svg_5" rx="88" ry="51.80065" stroke="#000" />
   </g>
   <g id="eye2">
      <ellipse stroke-width="3" ry="29.5" rx="29.5" id="svg_2" cy="168.5" cx="209.5" stroke="#000" fill="#fff" />
      <ellipse ry="3.5" rx="3" id="svg_4" cy="169.5" cx="208" stroke-width="3" fill="#000000" stroke="#000" />
   </g>
</svg>

SVG is a language defined in XML to describe two-dimensional vector and vector/raster graphics. It is widely used as it can be displayed in arbitrarily large sizes and without sacrificing image quality, it can be described using code, and it is easy to edit.

As can be seen from the above code combined with the following image, this SVG contains the following.

• An XML declaration in the first line, indicating the version and encoding type, followed by the width and height of the SVG;

• eye1: eye circle and black eyes drawn by two ellipses;

• head: ellipse filled with #4cc4c1 color as the body;

• eye2: identical to eye1, in a different position;

eye1, head and eye2 are superimposed in sequence to get the final shape.

Helper function

1. uint2str converts uint to string, like convert 123 to '123'

function uint2str(uint _i) internal pure returns (string memory _uintAsString) {
      if (_i == 0) {
          return "0";
      }
      uint j = _i;
            // uint length
      uint len;
      while (j != 0) {
          len++;
          j /= 10;
      }
      bytes memory bstr = new bytes(len);
      uint k = len;
      while (_i != 0) {
          k = k-1;
                // _i single digits
          uint8 temp = (48 + uint8(_i - _i / 10 * 10));
          bytes1 b1 = bytes1(temp);
          bstr[k] = b1;
          _i /= 10;
      }
      return string(bstr);
  }

1. ToColor.sol library: convert byte3 type to color strings. Eg. 0x4cc4c1 as input and '4cc4c1' as output.

library ToColor {
    bytes16 internal constant ALPHABET = '0123456789abcdef';

    function toColor(bytes3 value) internal pure returns (string memory) {
      bytes memory buffer = new bytes(6);
      for (uint256 i = 0; i < 3; i++) {
          buffer[i*2+1] = ALPHABET[uint8(value[i]) & 0xf];
          buffer[i*2] = ALPHABET[uint8(value[i]>>4) & 0xf];
      }
      return string(buffer);
    }
}

1. HexStrings.sol library: Mainly extract uint based on length index, just like extract 20 indices of address: (*uint160*(ownerOf(id))).toHexString(20), this expression generates the coresponding tokenId owner address.

library HexStrings {
    bytes16 internal constant ALPHABET = '0123456789abcdef';

    function toHexString(uint256 value, uint256 length) internal pure returns (string memory) {
        bytes memory buffer = new bytes(2 * length + 2);
        buffer[0] = '0';
        buffer[1] = 'x';
        for (uint256 i = 2 * length + 1; i > 1; --i) {
            buffer[i] = ALPHABET[value & 0xf];
            value >>= 4;
        }
        return string(buffer);
    }
}

That's it for the contract code analysis.

Below we will provide a brief analysis of the front-end logic, and then we will implement the NFT minting and display functionality step by step. Before submitting front-end code, follow the steps below to add the functionality.

0x03 Front end logic analysis

The project front-end files are in packages/react-app, and the locations of the files covered in the following articles will be found in this file.

check App.jsx：

https://github.com/qiwihui/scaffold-eth/blob/loogies-svg-nft/packages/react-app/src/App.jsx

First we take a look at src/App.jsx. It is the main component for the project. We can view it in our editor.

It has sections and functions of:

• Header: show title

• _NetworkDisplay: show network

• _Menu, Switch: show and switch menu

• _ThemeSwitch: switch light and dark theme

• _Account: show account info

• And two Rows show gas and supported faucet in the lower left corner

Then we take a look at _NetworkDisplay and Account's logic design, and functions in Menu, and Switch.

NetworkDisplay

Component is at: src/components/NetworkDisplay.jsx.

With those two functions:

1. Show current network;

2. If the current network is not supported, then show error. The network id for local network should be 31337.

function NetworkDisplay({
  NETWORKCHECK,
  localChainId,
  selectedChainId,
  targetNetwork,
  USE_NETWORK_SELECTOR,
  logoutOfWeb3Modal,
}) {
  let networkDisplay = "";
  if (NETWORKCHECK && localChainId && selectedChainId && localChainId !== selectedChainId) {
    const networkSelected = NETWORK(selectedChainId);
    const networkLocal = NETWORK(localChainId);
    if (selectedChainId === 1337 && localChainId === 31337) {
            // show error network id
            ...
    } else {
            // show network is not correct
            ...
    }
  } else {
    networkDisplay = USE_NETWORK_SELECTOR ? null : (
      // show network name
      <div style={{ zIndex: -1, position: "absolute", right: 154, top: 28, padding: 16, color: targetNetwork.color }}>
        {targetNetwork.name}
      </div>
    );
  }

  console.log({ networkDisplay });

  return networkDisplay;
}

Account

Component is at src/components/Account.jsx.

With those three functions:

1. show current address

2. show address balance

3. show Connect or Logout

When user clicks Connect, the front end calls loadWeb3Modal. This function is needed to connect with wallets such as MetaMask and listen to the wallet's _ chainChanged, accountsChanged and disconnect events, i.e. to modify the display status when we switch networks, select connected accounts and cancel connections in the wallet.

const loadWeb3Modal = useCallback(async () => {
  // connect wallet
  const provider = await web3Modal.connect();
  setInjectedProvider(new ethers.providers.Web3Provider(provider));
  // listen to network switch
  provider.on('chainChanged', (chainId) => {
    console.log(`chain changed to ${chainId}! updating providers`);
    setInjectedProvider(new ethers.providers.Web3Provider(provider));
  });
  // listen to changed accounts
  provider.on('accountsChanged', () => {
    console.log(`account changed!`);
    setInjectedProvider(new ethers.providers.Web3Provider(provider));
  });
  // Subscribe to session disconnection
  provider.on('disconnect', (code, reason) => {
    console.log(code, reason);
    logoutOfWeb3Modal();
  });
  // eslint-disable-next-line
}, [setInjectedProvider]);

Similarly, in the case of a connected wallet, the user clicks Logout to call the logoutOfWeb3Modal function.

const logoutOfWeb3Modal = async () => {
  // clear cached network provider and disconnect
  await web3Modal.clearCachedProvider();
  if (
    injectedProvider &&
    injectedProvider.provider &&
    typeof injectedProvider.provider.disconnect == 'function'
  ) {
    await injectedProvider.provider.disconnect();
  }
  setTimeout(() => {
    window.location.reload();
  }, 1);
};

Menu， Switch

These two correspond to the display menu and correspond to the switch menu functions, these menus include:

• App Home: the project wants us to put the functions we need to implement in this menu, such as the minting and display functions of NFT that we will implement.

• Debug Contracts: debug their own written contract functions, will be based on the contract's ABI file to show the state variables and functions that can be called.

• Hints: hints for coding.

• ExampleUI: sample UI, which can be used for programming purposes.

• Mainnet DAI: the state of the contracts and available functions of the DAI network, with the same functionality as Debug Contracts.

• Subgraph: Listening and querying for events in contracts using The Graph protocol.

Debug output

App.jsx also has debugging output that prints the current page status, allowing you to view the current status variables in real time during development.

//
// 🧫 DEBUG 👨🏻‍🔬
//
useEffect(() => {
  if (
    DEBUG &&
    mainnetProvider &&
    address &&
    selectedChainId &&
    yourLocalBalance &&
    yourMainnetBalance &&
    readContracts &&
    writeContracts &&
    mainnetContracts
  ) {
    console.log(
      '_____________________________________ 🏗 scaffold-eth _____________________________________',
    );
    console.log('🌎 mainnetProvider', mainnetProvider);
    console.log('🏠 localChainId', localChainId);
    console.log('👩‍💼 selected address:', address);
    console.log('🕵🏻‍♂️ selectedChainId:', selectedChainId);
    console.log(
      '💵 yourLocalBalance',
      yourLocalBalance ? ethers.utils.formatEther(yourLocalBalance) : '...',
    );
    console.log(
      '💵 yourMainnetBalance',
      yourMainnetBalance ? ethers.utils.formatEther(yourMainnetBalance) : '...',
    );
    console.log('📝 readContracts', readContracts);
    console.log('🌍 DAI contract on mainnet:', mainnetContracts);
    console.log('💵 yourMainnetDAIBalance', myMainnetDAIBalance);
    console.log('🔐 writeContracts', writeContracts);
  }
}, [
  mainnetProvider,
  address,
  selectedChainId,
  yourLocalBalance,
  yourMainnetBalance,
  readContracts,
  writeContracts,
  mainnetContracts,
  localChainId,
  myMainnetDAIBalance,
]);

After viewing the basic functions of the home page, we start implementing the two functions of NFT minting and displaying the NFT list.

0x04 NFT functions

We will implement the following three main components of functionality.

• Minting NFTs;

• Displaying the NFT list;

• Displaying a list of NFT contract interfaces.

Minting NFT

First we find the component corresponding to App Home, as you can see from the code below, which uses the Home component, located at src/views/Home.jsx.

    ...
    <Switch>
        <Route exact path="/">
          {/* pass in any web3 props to this Home component. For example, yourLocalBalance */}
          <Home yourLocalBalance={yourLocalBalance} readContracts={readContracts} />
        </Route>
    ....

Delete contents in Home.jsx and add the following Mint button:

import React, { useState } from 'react';
import { Button, Card, List } from 'antd';

function Home({ isSigner, loadWeb3Modal, tx, writeContracts }) {
  return (
    <div>
      {/* Mint button */}
      <div
        style={{
          maxWidth: 820,
          margin: 'auto',
          marginTop: 32,
          paddingBottom: 32,
        }}
      >
        {isSigner ? (
          <Button
            type={'primary'}
            onClick={() => {
              tx(writeContracts.YourCollectible.mintItem());
            }}
          >
            MINT
          </Button>
        ) : (
          <Button type={'primary'} onClick={loadWeb3Modal}>
            CONNECT WALLET
          </Button>
        )}
      </div>
    </div>
  );
}

export default Home;

Change Switch's component into:

      ...
      <Switch>
        <Route exact path="/">
          {/* pass in any web3 props to this Home component. For example, yourLocalBalance */}
          <Home
            isSigner={userSigner}
            loadWeb3Modal={loadWeb3Modal}
            tx={tx}
            writeContracts={writeContracts}
          />
       ...

It should look like this:

After clicking Mint, we can see that the transaction was successfully issued, at this point, although we successfully minted the NFT, we still need to add the list to show our NFT.

Show NFT list

Add a list to display containing the NFT can be transferred to other addresses.

import React, { useState } from 'react';
import { Button, Card, List } from 'antd';
import { useContractReader } from 'eth-hooks';
import { Address, AddressInput } from '../components';

function Home({
  isSigner,
  loadWeb3Modal,
  yourCollectibles,
  address,
  blockExplorer,
  mainnetProvider,
  tx,
  readContracts,
  writeContracts,
}) {
  const [transferToAddresses, setTransferToAddresses] = useState({});

  return (
    <div>
      {/* Mint button */}
      ...
      {/* List */}
      <div style={{ width: 820, margin: 'auto', paddingBottom: 256 }}>
        <List
          bordered
          dataSource={yourCollectibles}
          renderItem={(item) => {
            const id = item.id.toNumber();
            console.log('IMAGE', item.image);
            return (
              <List.Item key={id + '_' + item.uri + '_' + item.owner}>
                <Card
                  title={
                    <div>
                      <span style={{ fontSize: 18, marginRight: 8 }}>
                        {item.name}
                      </span>
                    </div>
                  }
                >
                  <a
                    href={
                      'https://opensea.io/assets/' +
                      (readContracts &&
                        readContracts.YourCollectible &&
                        readContracts.YourCollectible.address) +
                      '/' +
                      item.id
                    }
                    target='_blank'
                  >
                    <img src={item.image} />
                  </a>
                  <div>{item.description}</div>
                </Card>
                {/* NFT transfering */}
                <div>
                  owner:{' '}
                  <Address
                    address={item.owner}
                    ensProvider={mainnetProvider}
                    blockExplorer={blockExplorer}
                    fontSize={16}
                  />
                  <AddressInput
                    ensProvider={mainnetProvider}
                    placeholder='transfer to address'
                    value={transferToAddresses[id]}
                    onChange={(newValue) => {
                      const update = {};
                      update[id] = newValue;
                      setTransferToAddresses({
                        ...transferToAddresses,
                        ...update,
                      });
                    }}
                  />
                  <Button
                    onClick={() => {
                      console.log('writeContracts', writeContracts);
                      tx(
                        writeContracts.YourCollectible.transferFrom(
                          address,
                          transferToAddresses[id],
                          id,
                        ),
                      );
                    }}
                  >
                    Transfer
                  </Button>
                </div>
              </List.Item>
            );
          }}
        />
      </div>
      {/* Display info */}
      <div
        style={{
          maxWidth: 820,
          margin: 'auto',
          marginTop: 32,
          paddingBottom: 256,
        }}
      >
        🛠 built with{' '}
        <a
          href='https://github.com/austintgriffith/scaffold-eth'
          target='_blank'
        >
          🏗 scaffold-eth
        </a>
        🍴 <a
          href='https://github.com/austintgriffith/scaffold-eth'
          target='_blank'
        >
          Fork this repo
        </a> and build a cool SVG NFT!
      </div>
    </div>
  );
}

export default Home;

Change the component into:

      ...
      <Switch>
        <Route exact path="/">
          {/* pass in any web3 props to this Home component. For example, yourLocalBalance */}
          <Home
            isSigner={userSigner}
            loadWeb3Modal={loadWeb3Modal}
            yourCollectibles={yourCollectibles}
            address={address}
            blockExplorer={blockExplorer}
            mainnetProvider={mainnetProvider}
            tx={tx}
            writeContracts={writeContracts}
            readContracts={readContracts}
          />
       ...

It should look like this:

But we found that when we mint again, the list doesn't update, it's still the same, so we need to add an event listener to App.jsx that will refresh the list once we mint NFT:

// Track current NFT numbers
const balance = useContractReader(
  readContracts,
  'YourCollectible',
  'balanceOf',
  [address],
);
console.log('🤗 balance:', balance);

const yourBalance = balance && balance.toNumber && balance.toNumber();
const [yourCollectibles, setYourCollectibles] = useState();
//
// 🧠 This useEffect hook updates yourCollectibles when balance is changing.
//
useEffect(() => {
  const updateYourCollectibles = async () => {
    const collectibleUpdate = [];
    for (let tokenIndex = 0; tokenIndex < balance; tokenIndex++) {
      try {
        console.log('GEtting token index', tokenIndex);
        const tokenId = await readContracts.YourCollectible.tokenOfOwnerByIndex(
          address,
          tokenIndex,
        );
        console.log('tokenId', tokenId);
        const tokenURI = await readContracts.YourCollectible.tokenURI(tokenId);
        const jsonManifestString = atob(tokenURI.substring(29));
        console.log('jsonManifestString', jsonManifestString);

        try {
          const jsonManifest = JSON.parse(jsonManifestString);
          console.log('jsonManifest', jsonManifest);
          collectibleUpdate.push({
            id: tokenId,
            uri: tokenURI,
            owner: address,
            ...jsonManifest,
          });
        } catch (e) {
          console.log(e);
        }
      } catch (e) {
        console.log(e);
      }
    }
    setYourCollectibles(collectibleUpdate.reverse());
  };
  updateYourCollectibles();
}, [address, yourBalance]);

At this point, when we mint again, the list is automatically updated to show the latest NFT.

Show NFT contract ABI list

This function is relatively simple and requires only the following changes to the corresponding debug section:

      <Route exact path="/debug">
          {/*
                🎛 this scaffolding is full of commonly used components
                this <Contract/> component will automatically parse your ABI
                and give you a form to interact with it locally
            */}

          <Contract
            name="YourCollectible"
            price={price}
            signer={userSigner}
            provider={localProvider}
            address={address}
            blockExplorer={blockExplorer}
            contractConfig={contractConfig}
          />

更新之后，可以在 Debug Contracts 菜单下看到合约的可以调用的函数。

After the update, you can see the callable functions of the contract under the Debug Contracts menu:

At this point, we are done with a simple NFT minting and display DApp.

0x05 Conclusion

Through this project, we learnt and understood the following knowledge:

1. the basic of NFT contracts and how to upload NFT in marketplaces such as OpenSea.

2. how the DApp front-end connects to wallets such as MetaMask.

3. how to call contract functions on the front end.

国内用户如需交流，可加微信：197626581.

MoonbeamScan ：

https://moonbeam.moonscan.io/

Web3DevNFT Contract in this article：

https://moonbeam.moonscan.io/address/0xb6FC950C4bC9D1e4652CbEDaB748E8Cdcfe5655F

Basic Concept

What is a Syncer? It's a scheduled job to retrieve transactions from one contract regularly and persist them locally.

The Syncer has two main parts:

• Syncer: responsible for retrieving transactions from the contract and persistence handling.

• Syncer Server: repsonsible for job scheduling and monitoring.

• Parser：Parse the transactions.

Syncer is useful, because it formats and caches on-chain data, allowing various dApps and services to read on-chain data more quickly, improving the experience.

The traditional Syncer is implemented by connecting blockchain nodes, which has the advantage of being more stable, but we also have a lighter option -- to implement Syncer by calling the API of the Etherscan-like browser! Etherscan provides an interface to get all transactions of a specific contract, so we can do Syncer with lower complexity. This doesn't sound so Web3 because Syncer relies on the browser service to function properly, but in most scenarios, it works well!

Implementation in Elixir

Repo：

https://github.com/WeLightProject/tai_shang_nft_gallery

Syncer

The processing logic of Syncer contain below three main steps:

1. Retrieves the latest block number of the blockchain.

2. Based on the last locally persited block number, retrieves transactions from the chain using Etherscan API and persist locally.

3. Update last block number of the contract locally.

# https://github.com/WeLightProject/tai_shang_nft_gallery/blob/main/lib/tai_shang_nft_gallery/nft/syncer.ex

defmodule TaiShangNftGallery.Nft.Syncer do
  alias TaiShangNftGallery.NftContract
  alias TaiShangNftGallery.TxHandler
  alias TaiShangNftGallery.Chain.Fetcher
  alias TaiShangNftGallery.ScanInteractor
  require Logger

  @api_keys %{
    "Moonbeam" => System.get_env("MOONBEAM_API_KEY")
  }
  def sync(chain, %{last_block: last_block} = nft_contract) do

    # Step 1
    best_block = Fetcher.get_block_number(chain)
    # Step 2
    do_sync(chain, nft_contract, last_block, best_block)
    # Step 3
    NftContract.update(
      nft_contract,
      %{last_block: best_block + 1}
    )
  end

  def do_sync(%{name: name} = chain, %{addr: addr} = nft_contract, last_block, best_block) do
    # Step 2.1 - Retrieves Txns by Etherscan API
    {:ok, %{"result" => txs}}=
      ScanInteractor.get_txs_by_contract_addr(
        chain,
        addr,
        last_block,
        best_block,
        @api_keys[name]
      )

    # Step 2.2 - Persist transactions locally
    handle_txs(chain, nft_contract, txs)
  end

  def handle_txs(chain, nft_contract, txs) do
    Enum.each(txs, fn tx ->
      Logger.info("Handling tx: #{inspect(tx)}")
      tx_atom_map = ExStructTranslator.to_atom_struct(tx)
      TxHandler.handle_tx(chain, nft_contract, tx_atom_map)
    end)
  end
end

Syncer Server

Syncer Server is implemented by GenServer. For those who do not know about it, you can imagine that it's some kind of process that runs forever. If there is any error, it can automatically restart.

The GenServer operates by handling the messages received, from itself or others. There are two main functions here:

• init: The initialization function. It loads the Contract locally, store it in the process state and sends itself a :sync message.

• handle_info: The :sync message handler that calls the API of the Syncer to do the actual work.

After each processing, the Process.send_after/3 function sends itself a :sync message after 10 minutes.

# https://github.com/WeLightProject/tai_shang_nft_gallery/blob/main/lib/tai_shang_nft_gallery/syncer_server.ex
defmodule TaiShangNftGallery.SyncerServer do
  @moduledoc """
    Genserver as Syncer
  """
  alias TaiShangNftGallery.Nft.Syncer
  alias TaiShangNftGallery.NftContract
  use GenServer
  require Logger

  @sync_interval 600_000 # 10 minutes
  # +-----------+
  # | GenServer |
  # +-----------+
  def start_link(state) do
    GenServer.start_link(__MODULE__, state, name: :"#nft_syncer")
  end

  def init([nft_contract_id: nft_contract_id]) do
    Logger.info("SyncerServer started yet.")
    nft_contract =
      nft_contract_id
      |> NftContract.get_by_id()
      |> NftContract.preload()
      state =
        [nft_contract: nft_contract]
    send(self(), :sync)
    {:ok, state}
  end

  def handle_info(:sync, [nft_contract: nft_contract] = state) do
    Syncer.sync(nft_contract.chain, nft_contract)
    sync_after_interval()
    {:noreply, state}
  end

  def sync_after_interval() do
    Process.send_after(self(), :sync, @sync_interval)
  end
end

Decode Transaction

Different transactions actually represent different contract method call. In order to identify what exactly the transaction is doing, we have to decode the transaction input because the input is a hex value like 0x379607f5000000000000000000000000000000000000000000000000000000000000026d. TxHandler.handle_tx/3 uses ABI related APIs encapsulated in ABIHandler.find_and_decode/2 to accomplish that.

# https://github.com/WeLightProject/tai_shang_nft_gallery/blob/main/lib/tai_shang_nft_gallery/tx_handler.ex
defmodule TaiShangNftGallery.TxHandler do
  @moduledoc """
      Handle Ethereum Tx.
  """

  alias TaiShangNftGallery.ABIHandler
  alias TaiShangNftGallery.NftContract

  def handle_tx(chain, nft_contract, tx) do
    %{
      from: from,
      to: to,
      value: value,
      input: input
    } = tx

    do_handle_tx(chain, from, to, value, input, nft_contract)
  end

  def do_handle_tx(chain, from, to, value, input, %{type: type} = nft_contract) do
    input_handled =
      nft_contract
      |> NftContract.preload(:deep)
      |> Map.get(:contract_abi)
      |> Map.get(:abi)
      |> ABIHandler.find_and_decode(input)

    "Elixir.TaiShangNftGallery.TxHandler.#{type}"
    |> String.to_atom()
    |> apply(:handle_tx, [chain, nft_contract, from, to, value, input_handled])
  end
end

# https://github.com/WeLightProject/tai_shang_nft_gallery/blob/main/lib/tai_shang_nft_gallery/abi_handler.ex
defmodule TaiShangNftGallery.ABIHandler do
  alias Utils.TypeTranslator
  def find_and_decode(abi, input_hex) do
    abi
    |> ABI.parse_specification
    |> ABI.find_and_decode(TypeTranslator.hex_to_bin(input_hex))
  end
end

In the exact contract handler (type Web3Dev), we can see that only below methods are handled. Other than those, it returns {:ok, "pass"} directly.

• safeTransferFrom / trasnferFrom: Used to transfer the ownership of the NFT

• claim: Used to initialize the NFT token

• setTokenInfo: Used to set NFT token info

# https://github.com/WeLightProject/tai_shang_nft_gallery/blob/main/lib/tai_shang_nft_gallery/tx_handler/web_3_dev.ex
defmodule TaiShangNftGallery.TxHandler.Web3Dev do
  alias TaiShangNftGallery.Nft
  alias TaiShangNftGallery.Nft.Interactor
  alias Utils.TypeTranslator

  require Logger
  def handle_tx(chain, nft_contract, from, to, value,
    {%{function: func_name}, data})  do
      do_handle_tx(
        func_name,
        nft_contract, from, to, value, data, chain
      )
  end

  def handle_tx(_chain, _nft_contract, _from, _to, _value, _others) do
    :pass
  end

  def do_handle_tx(func, _nft_contract, from, _to, _value,
    [_from_bin, to_bin, token_id], _chain) when
    func in ["safeTransferFrom", "transferFrom"] do
    # Change Owner
    to_str = TypeTranslator.bin_to_addr(to_bin)
    Logger.info("Transfer NFT from #{from} to #{to_str}")
    nft = Nft.get_by_token_id(token_id)
    Nft.update(nft, %{token_id: token_id, owner: to_str})
  end

  def do_handle_tx("claim", %{id: nft_c_id, addr: addr}, from, _to, _value, [token_id], chain) do
    # INIT Token
    uri = Interactor.get_token_uri(chain, addr, token_id)
    Nft.create(
      %{
        uri: uri,
        token_id: token_id,
        owner: from,
        nft_contract_id: nft_c_id
    })
  end

  def do_handle_tx(
    "setTokenInfo",
    %{id: nft_c_id}, _from, _to, _value,
    [token_id, badges_raw], _chain) do
    # UPDATE TokenInfo

    token_id
    |> Nft.get_by_token_id_and_nft_contract_id(nft_c_id)
    |> Nft.update(%{
        badges: Poison.decode!(badges_raw), token_id: token_id
    }, :with_badges)
  end

  def do_handle_tx(_others, _, _, _, _, _, _) do
    {:ok, "pass"}
  end
end

Implementation in Node.js

See code in:

https://github.com/WeLightProject/Web3-dApp-Camp/tree/main/blockchain-server/syncer/syncer_demo_js

Syncer

Let's see how do we implement the Syncer in Node.js. Using APIs provided by Web3 and Moonbeam, it's very easy to interact with Moonbeam chain.

getBlockNumber

web3.eth.getBlockNumber([callback])Returns the current block number.

Returns

Promise returns Number - The number of the most recent block.

Get a list of 'Normal' Transactions By Address

[Optional Parameters] startblock: starting blockNo to retrieve results, endblock: ending blockNo to retrieve results

https://api-moonbeam.moonscan.io/api?module=account&action=txlist&address=0x0000000000000000000000000000000000001004&startblock=1&endblock=99999999&sort=asc&apikey=YourApiKeyToken(Returned 'isError' values: 0=No Error, 1=Got Error)(Returns up to a maximum of the last 10000 transactions only)

or

https://api-moonbeam.moonscan.io/api?module=account&action=txlist&address=0x0000000000000000000000000000000000001004&startblock=1&endblock=99999999&page=1&offset=10&sort=asc&apikey=YourApiKeyToken(To get paginated results use page= and offset=)

Below is Syncer implemented in JavaScript. In this example, I persist the data using sqlite but you can choose anything you are familiar with. And I simply use setTimeout and Catch-All-Error approach to simulate a forever running process.

import Web3 from 'web3';
import got from 'got';
import sqlite3 from 'sqlite3';
import abiDecoder from 'abi-decoder';

const db = new sqlite3.Database('./sqlite.db');

const web3 = new Web3(new Web3.providers.HttpProvider('https://rpc.api.moonbeam.network'));

const INTERVAL = 1 * 60 * 1000; // 10 minutes
const API_KEY = 'Y6AIFQQVAJ3H38CC11QFDUDJWAWNCWE3U8';

const CONTRACT_ADDRESS = '0xb6FC950C4bC9D1e4652CbEDaB748E8Cdcfe5655F';
const CONTRACT_ABI = []; // ABI can be retrieved from https://moonbeam.moonscan.io/address/0xb6FC950C4bC9D1e4652CbEDaB748E8Cdcfe5655F#code

abiDecoder.addABI(CONTRACT_ABI);

async function sync() {
  try {
    const contract = await getContractInfo(CONTRACT_ADDRESS);

    // Step 1 - Retrieves the latest block number of the blockchain
    const latestBlock = await web3.eth.getBlockNumber();
    console.log(`Latest blockNumber is: ${latestBlock}`);

    const lastBlockNumber = contract.lastBlockNumber || latestBlock - 100000;

    // Step 2.1 - Retrieves Txns by Etherscan API
    const transactions = await getTransactionsOfContract(contract.address, lastBlockNumber, latestBlock);
    console.log(`${transactions.length} transactions retrieved from Block ${lastBlockNumber} to ${latestBlock}.`);

    if (transactions.length > 0) {
      // Step 2.2 - Handle transactions
      await handleTransactions(contract, transactions);
    }

    // Step 3 - Persist the latest block number
    contract.lastBlockNumber = latestBlock + 1;
    await updateContractLastBlockNumber(contract);
    console.log(`lastBlockNumber of contract ${contract.id} is updated to ${contract.lastBlockNumber}.`);
  } catch (error) {
    console.error('Failed to sync transactions.', error);
  }

  nextRun();
}

function nextRun() {
  setTimeout(sync, INTERVAL);
}

async function getTransactionsOfContract(contractAddress, fromBlock, toBlock) {
  const url = `https://api-moonbeam.moonscan.io/api?module=account&action=txlist&address=${contractAddress}&startblock=${fromBlock}&endblock=${toBlock}&sort=asc&apikey=${API_KEY}`;
  const response = await got(url).json();

  return response.result;
}

async function _getContract(address) {
  return new Promise(function (resolve, reject) {
    db.get('SELECT id, lastBlockNumber, address FROM contract WHERE address = $address', { $address: address }, function (err, result) {
      if (err) {
        return reject(err);
      }

      return resolve(result);
    });
  });
}

async function getContractInfo(address) {
  let contract = await _getContract(address);
  if (contract) {
    return contract;
  }

  contract = {
    lastBlockNumber: 0,
    address
  };
  const contractId = await _runSQL(
    'INSERT INTO contract (lastBlockNumber, address) VALUES ($lastBlockNumber, $address)',
    {
      $lastBlockNumber: contract.lastBlockNumber,
      $address: contract.address
    }
  );
  contract.id = contractId;
  return contract;
}

async function updateContractLastBlockNumber(contract) {
  return _runSQL(
    'UPDATE contract SET lastBlockNumber = $lastBlockNumber WHERE id = $id',
    {
      $lastBlockNumber: contract.lastBlockNumber,
      $id: contract.id
    }
  );
}

async function execute() {
  // SQLite DB tables should be initialized first.

  await sync();
}

execute();

Decode Transactions

In order to decode the transaction, we need to unitilize the APIs provided by Web3.

encodeFunctionCall

web3.eth.abi.encodeFunctionCall(jsonInterface, parameters);Encodes a function call using its JSON interface object and given parameters.

Parameters

1. jsonInterface - Object: The JSON interface object of a function.

2. parameters - Array: The parameters to encode.

3. Function - (optional) Optional callback, returns an error object as first parameter and the result as second.

Returns

String - The ABI encoded function call. Means function signature + parameters.

Example

web3.eth.abi.encodeFunctionCall({
  name: 'myMethod',
  type: 'function',
  inputs: [{
      type: 'uint256',
      name: 'myNumber'
  },{
      type: 'string',
      name: 'myString'
  }]
}, ['2345675643', 'Hello!%']);
"0x24ee0097000000000000000000000000000000000000000000000000000000008bd02b7b0000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000748656c6c6f212500000000000000000000000000000000000000000000000000"

call

web3.eth.call(callObject [, defaultBlock] [, callback])Executes a message call transaction, which is directly executed in the VM of the node, but never mined into the blockchain.

Parameters

1. Object - A transaction object, see web3.eth.sendTransaction. For calls the from property is optional however it is highly recommended to explicitly set it or it may default to address(0) depending on your node or provider.

2. Number|String|BN|BigNumber - (optional) If you pass this parameter it will not use the default block set with web3.eth.defaultBlock. Pre-defined block numbers as "earliest", "latest" and "pending" can also be used.

3. Function - (optional) Optional callback, returns an error object as first parameter and the result as second.

Returns

Promise returns String - The returned data of the call, e.g. a smart contract functions return value.

Example

web3.eth.call({
  to: "0x11f4d0A3c12e86B4b5F39B213F7E19D048276DAe", // contract address
  data: "0xc6888fa10000000000000000000000000000000000000000000000000000000000000003"
})
.then(console.log);
"0x000000000000000000000000000000000000000000000000000000000000000a"

hexToUtf8

web3.utils.hexToUtf8(hex)Returns the UTF-8 string representation of a given HEX value.

Parameters

1. hex - String: A HEX string to convert to a UTF-8 string.

Returns

String: The UTF-8 string.

Example

web3.utils.hexToUtf8('0x49206861766520313030e282ac');
"I have 100€"

const TRANSACTION_HANDLER = {
  safeTransferFrom: transferHandler,
  transferFrom: transferHandler,
  claim: claimHandler
}

async function handleTransactions(contract, transactions) {
  for (let i = 0; i < transactions.length; i++) {
    const transaction = transactions[i];
    const decodedMethod = abiDecoder.decodeMethod(transaction.input);

    const handler = TRANSACTION_HANDLER[decodedMethod.name];
    if (handler) {
      await handler(contract, transaction, decodedMethod.params);
    }
  }
}

/**
 * Transfer the ownership of the NTF token
 * @param {*} contract The NFT contract
 * @param {*} transaction The transaction executing the claim method
 * @param {*} params Decoded parameters provided to the method.  Sample:
 *  [
 *    {
 *      name: 'from',
 *      value: '0xc994b5384c0d0611de2ece7d6ff1ad16c34a812f',
 *      type: 'address'
 *    },
 *    {
 *      name: 'to',
 *      value: '0x9c88a415f6a8043d7eaf14db721efbd8309e7365',
 *      type: 'address'
 *    },
 *    { name: 'tokenId', value: '888888', type: 'uint256' }
 *  ]
 */
async function transferHandler(contract, transaction, params) {
  const to = _getParam(params, 'to').value;
  const tokenId = parseInt(_getParam(params, 'tokenId').value);

  return _runSQL(
    `UPDATE nft SET owner = $owner WHERE contractId = $contractId and tokenId = $tokenId`,
    { $owner: to, $contractId: contract.id, $tokenId: tokenId }
  );
}

/**
 * Initialize the NFT token
 * @param {*} contract The NFT contract
 * @param {*} transaction The transaction executing the claim method
 * @param {*} params Decoded parameters provided to the method.  Sample: [{ name: 'tokenId', value: '199398', type: 'uint256' }]
 */
async function claimHandler(contract, transaction, params) {
  const tokenId = parseInt(_getParam(params, 'tokenId').value);
  const uri = await getTokenUri(contract.address, tokenId);

  const nft = {
    $contractId: contract.id,
    $tokenId: tokenId,
    $uri: uri,
    $owner: transaction.from,
  };

  return _runSQL(
    `INSERT INTO nft (contractId, tokenId, uri, owner) VALUES ($contractId, $tokenId, $uri, $owner)`,
    nft
  );
}

async function getTokenUri(contractAddress, tokenId) {
  const data = web3.eth.abi.encodeFunctionCall({
    name: 'tokenURI',
    type: 'function',
    inputs: [{
      type: 'uint256',
      name: 'tokenId'
    }]
  }, [tokenId]);

  const uriHex = await web3.eth.call({
    to: contractAddress, // contract address
    data
  });

  return web3.utils.hexToUtf8(uriHex);
}

Authors: