├── .github
└── workflows
│ └── ReopBot.yml
├── 317232.md
├── CHENFANGC.md
├── ChinesePaladin61.md
├── CornellZheng
├── CornellZheng.md
├── Helen2022a.md
├── HeliosLz.md
├── HenryWei.md
├── JacksonStack.md
├── LunaWang5209
├── Marcus.md
├── Muyec.md
├── NSXX2021.md
├── README.md
├── Rey666666.md
├── Soleil-YSY.md
├── StarryDesert.md
├── YOUKUAIHAOMUTOU.md
├── Yi-fantasy.md
├── YuanboXie.md
├── a-super-cat.md
├── fuhaooo.md
├── happylucie.md
├── hechichu.md
├── iavl.md
├── jiejie.md
├── jjeejj.md
├── joyc.md
├── linyuanye3.md
├── missingtheway.md
├── nocb.md
├── noyyyy.md
├── onthebigtree.md
├── pillowtalk-Qy.md
├── pliker-git.md
├── stualan.md
├── sync_status_readme.py
├── wimawang
├── wodeche.md
└── yuhui.md
/.github/workflows/ReopBot.yml:
--------------------------------------------------------------------------------
1 | name: Repo Management
2 |
3 | on:
4 | pull_request_target:
5 | types: [closed]
6 | schedule:
7 | - cron: "0 0 * * *" # 每天午夜运行
8 | push:
9 | branches: [main] # 每次推送到main分支时也运行
10 |
11 | permissions:
12 | contents: write
13 | pull-requests: write
14 |
15 | jobs:
16 | invite-contributor:
17 | runs-on: ubuntu-latest
18 | if: github.event_name == 'pull_request_target' && github.event.pull_request.merged == true
19 | steps:
20 | - name: Invite contributor
21 | id: invite-contributor
22 | uses: actions/github-script@v6
23 | with:
24 | github-token: ${{ secrets.PAT_WITH_INVITE_PERMISSIONS }}
25 | script: |
26 | const { owner, repo } = context.repo;
27 | const username = context.payload.pull_request.user.login;
28 |
29 | console.log(`Checking if ${username} is already a collaborator...`);
30 |
31 | try {
32 | const { data: permissionLevel } = await github.rest.repos.getCollaboratorPermissionLevel({
33 | owner,
34 | repo,
35 | username,
36 | });
37 |
38 | if (permissionLevel.permission === 'admin' || permissionLevel.permission === 'write') {
39 | console.log(`${username} is already a collaborator with sufficient permissions.`);
40 | return;
41 | }
42 |
43 | console.log(`${username} is a collaborator but needs permission update.`);
44 | } catch (error) {
45 | if (error.status !== 404) {
46 | console.error(`Error checking collaborator status: ${error.message}`);
47 | throw error;
48 | }
49 | console.log(`${username} is not a collaborator.`);
50 | }
51 |
52 | try {
53 | console.log(`Inviting ${username} as a collaborator...`);
54 | const response = await github.rest.repos.addCollaborator({
55 | owner,
56 | repo,
57 | username,
58 | permission: 'push'
59 | });
60 |
61 | if (response.status === 201) {
62 | console.log(`Invitation sent to ${username} as a collaborator with push permission.`);
63 | core.setOutput('invitation_sent', 'true');
64 | } else if (response.status === 204) {
65 | console.log(`${username}'s permissions updated to push.`);
66 | core.setOutput('invitation_sent', 'false');
67 | }
68 | } catch (error) {
69 | console.error(`Error inviting/updating collaborator: ${error.message}`);
70 | core.setFailed(`Error inviting/updating collaborator: ${error.message}`);
71 | }
72 |
73 | - name: Comment on PR
74 | if: steps.invite-contributor.outputs.invitation_sent == 'true'
75 | uses: actions/github-script@v6
76 | with:
77 | github-token: ${{ secrets.GITHUB_TOKEN }}
78 | script: |
79 | const { owner, repo } = context.repo;
80 | const issue_number = context.payload.pull_request.number;
81 | const username = context.payload.pull_request.user.login;
82 | try {
83 | await github.rest.issues.createComment({
84 | owner,
85 | repo,
86 | issue_number,
87 | body: `Thanks for your contribution, @${username}! You've been invited as a collaborator with push permissions. Please check your email for the invitation.`
88 | });
89 | console.log(`Comment posted on PR #${issue_number}`);
90 | } catch (error) {
91 | console.error(`Error posting comment: ${error.message}`);
92 | core.setFailed(`Error posting comment: ${error.message}`);
93 | }
94 |
95 | update-readme:
96 | runs-on: ubuntu-latest
97 | if: github.event_name == 'schedule' || github.event_name == 'push'
98 | steps:
99 | - uses: actions/checkout@v2
100 | - name: Set up Python
101 | uses: actions/setup-python@v2
102 | with:
103 | python-version: "3.x"
104 | - name: Install dependencies
105 | run: |
106 | python -m pip install --upgrade pip
107 | pip install PyGithub pytz
108 | - name: Update README
109 | env:
110 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
111 | START_DATE: ${{ vars.START_DATE }}
112 | END_DATE: ${{vars.END_DATE }}
113 | FILE_SUFFIX: ${{vars.FILE_SUFFIX}}
114 | FIELD_NAME: ${{vars.FIELD_NAME}}
115 | run: python sync_status_readme.py
116 | - name: Check for changes
117 | id: git-check
118 | run: |
119 | git diff --exit-code README.md || echo "modified=true" >> $GITHUB_OUTPUT
120 | - name: Commit changes
121 | if: steps.git-check.outputs.modified == 'true'
122 | run: |
123 | git config --local user.email "action@github.com"
124 | git config --local user.name "GitHub Action"
125 | git add README.md
126 | git commit -m "Update commit status table"
127 | git push
128 |
129 | notify-api:
130 | runs-on: ubuntu-latest
131 | if: github.event_name == 'pull_request_target' && github.event.pull_request.merged == true || github.event_name == 'push'
132 | steps:
133 | - name: Setup Node.js
134 | uses: actions/setup-node@v3
135 | with:
136 | node-version: "16"
137 |
138 | - name: Install axios
139 | run: npm install axios
140 |
141 | - name: Call API
142 | uses: actions/github-script@v6
143 | with:
144 | github-token: ${{ secrets.GITHUB_TOKEN }}
145 | script: |
146 | const axios = require('axios');
147 | const commit_sha = context.sha;
148 | const { owner, repo } = context.repo;
149 |
150 | try {
151 | const { data: commit } = await github.rest.repos.getCommit({
152 | owner,
153 | repo,
154 | ref: commit_sha
155 | });
156 |
157 | // Get user details
158 | const { data: user } = await github.rest.users.getByUsername({
159 | username: commit.author.login
160 | });
161 |
162 |
163 | // Output information
164 | console.log('Commit Author Information:');
165 | console.log('------------------------');
166 | console.log(`Name: ${commit.commit.author.name}`);
167 | console.log(`Email: ${commit.commit.author.email}`);
168 | console.log(`GitHub Username: ${commit.author.login}`);
169 | console.log(`User ID: ${user.id}`);
170 | console.log(`Account Type: ${user.type}`);
171 | console.log(`Created At: ${user.created_at}`);
172 |
173 | const response = await axios.get(`https://api.intensivecolearn.ing/api/programs/createByRepo/${owner}/${repo}`);
174 |
175 | console.log('API response:', response.data);
176 |
177 | const updateUserNotesResp = await axios.get(`https://api.intensivecolearn.ing/api/programs/updateStudynotes?owner=${owner}&repo=${repo}&userGitId=${user.id}`);
178 |
179 | console.log('updateUserNotesRespAPI response:', updateUserNotesResp.data);
180 |
181 | } catch (error) {
182 | console.error('Error calling API:', error.message);
183 | core.setFailed(`Error calling API: ${error.message}`);
184 | }
185 |
--------------------------------------------------------------------------------
/317232.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # {mwo}
55 |
56 | 1. Hi ! my name is mwo,I am a new member of the community, and I want to integrate into the community faster and learn web3 knowledge
57 | 3. 你认为你会完成本次残酷学习吗？
58 | yes
59 |
60 | ## Notes
61 |
62 |
63 |
64 | ### 2024.12.10
65 |
66 | 一.Arbitum的介绍
67 | 1.Arbitum使以太坊交易更便捷，更快
68 |
69 | 2.Arbitum具有检验和验证欺诈行为,裁决（adjudicate）和证明在L1上的欺诈是Arbitum的关键，
70 |
71 | 3.Arbitum是公开性的，任何人都可以看到Arbitum的验证过程，并且可以无条件的成为Arbitum的验证者
72 |
73 | 4.Arbitum可以以压缩数据事务的形式发布在L1上（允许任何人作为验证器进行无权限连接）,从而进一步减少事务在L1上的占用。
74 |
75 | 5.Arbitrum的创建以以太坊的兼容性为首要任务。这意味着用户可以在所有他们喜欢的以太坊钱包中使用Arbitrum；开发人员可以使用他们最喜欢的以太坊库和工具构建和部署合约。
76 |
77 | 6.最新版Arbitrum技术栈，称为Stylus，保留了Nitro的以太坊兼容性，同时增加了强大的新功能，即用Rust、c++等编程语言编写高性能智能合约的能力。
78 |
79 | 7.目前常用的Arbitrum链：一条是Arbitrum Rollup链，名为“Arbitrum one”，另一条是AnyTrust链，名为“Nova”；用户和开发人员可以选择适合其安全性/交易成本需求的任何选项。
80 |
81 | ### 2024.12.11
82 | Arbitrum 的创建以以太坊兼容性为首要任务。这意味着用户可以将 Arbitrum 与所有他们喜欢的以太坊钱包一起使用；开发人员可以使用所有他们喜欢的以太坊库和工具构建和部署合约；事实上，大多数时候，使用 Arbitrum 的体验与使用以太坊的体验相同（重要的一点是它更便宜、更快）。
83 | ### 2024.12.12
84 | **Arbitum**的第一个实现-自动售货机
85 |
86 | 介绍：Solidity智能合约建立一个数字纸杯蛋糕自动售货机
87 |
88 | 核心主张：Arbitrum使您可以轻松地将自动售货机部署到以太坊的无许可，无信任，分散的节点网络2，同时为您和您的用户保持低成本。
89 |
90 | Solidity快速入门总结：
91 |
92 | 1.确定了**两个业务规则**：1）公平且无需许可的纸杯蛋糕分发，2）不可变的业务逻辑和数据。
93 |
94 | 2.确定了一个**挑战**：这些规则在集中式应用程序中很难遵循。
95 |
96 | 3.确定了一个**解决方案**：Arbitrum 使开发人员可以轻松地分散业务逻辑和数据（使用以太坊主网作为结算层）。
97 |
98 | 4.将自动售货机的 Javascript 业务逻辑转换为**Solidity 智能合约**。
99 |
100 | 5.**将我们的智能合约部署**到 Hardhat 的本地开发网络，然后是 Arbitrum 的 Sepolia 测试网，然后是 Arbitrum One 主网。
101 | ### 2024.12.13
102 | 三.了解不同的 Arbitrum 链及其技术堆栈
103 |
104 | **Arbitrum One**是一条第 2 层 (L2) 乐观汇总链，它实现 Arbitrum Rollup 协议并结算到以太坊的第 1 层 (L1) 链。它允许您构建高性能以太坊 dApp，具有低交易成本和以太坊级安全保证，无需引入额外的信任假设。这是通过Nitro技术堆栈实现的，这是一种“以 Geth 为核心”的架构，它为 Arbitrum One（和 Nova）提供了高级调用数据压缩、用于常见执行和故障证明的单独上下文、以太坊 L1 gas 兼容性等。
105 |
106 | **Arbitrum Nova**是 Arbitrum One 链的高性能替代方案。Arbitrum One 实现了纯粹无需信任的 Rollup 协议，而 Arbitrum Nova 实现了几乎无需信任的AnyTrust协议。
107 |
108 | **区别:**
109 |
110 | Arbitrum One 和 Arbitrum Nova 是专为实际使用而设计的生产链。它们连接到以太坊主网并处理真实、有价值的交易。它们都在底层使用 Arbitrum 的 Nitro 技术堆栈，但 Arbitrum One 实现了 Rollup 协议，而 Nova 实现了 AnyTrust 协议。Arbitrum One 专为一般用途而设计，为运行与以太坊兼容的智能合约提供了可扩展且经济高效的解决方案。另一方面，Arbitrum Nova 专为需要更高交易吞吐量且不需要 Rollup 提供的完全去中心化的应用程序而设计。
111 |
112 |
113 |
114 | ### 2024.12.14
115 | Arbitrum 和 以太坊概述 的区别
116 |
117 | Arbitrum的设计尽可能与以太坊兼容和一致，从其高级RPC到低级字节码以及介于两者之间的一切。具有以太坊构建经验的去中心化应用程序（dApp）开发人员可能会发现，在Arbitrum上构建几乎不需要新的特定知识。
118 |
119 | ### 2024.12.15
120 |
121 | 四.Arbitrum生产链选择
122 |
123 | Arbitrum One是一个第2层（L2）乐观汇总链，它实现了Arbitrum汇总协议，并结算到以太坊的第1层（L1）链。它允许您构建具有低交易成本和以太坊级安全保证的高性能以太坊去中心化应用程序，无需引入额外的信任假设。这是由Nitro技术栈实现的，Nitro是一种“Geth at the core”架构，它为Arbitrum One（和Nova）提供了高级的调用数据压缩、用于通用执行和故障证明的单独上下文、以太坊L1气体兼容性等。
124 |
125 | Arbitrum Nova是Arbitrum One链条的高性能替代品。Arbitrum One实现了纯粹的无信任汇总协议，而Arbitrum Nova实现了大部分无信任的AnyTrust协议。Rollup和AnyTrust之间的关键区别在于，AnyTrust协议以数据可用性委员会（DAC）的形式引入了额外的信任假设。该委员会（详见下文）负责加快将L2交易数据存储、批处理和发布到以太坊L1的过程。这使您可以在需要性能和可负担性的场景中使用Arbitrum，而Arbitrum One最适合需要以太坊纯粹无信任的场景
126 |
127 |
128 | Arbitrum Sepolia是一个复制Arbitrum One主网功能的测试网链。它与Sepolia测试网相连，为开发人员提供了一个安全的平台，可以在主网实际部署之前对其智能合约进行实验和评估。
129 |
130 |
--------------------------------------------------------------------------------
/CHENFANGC.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # Cora
55 |
56 | 1. 自我介绍
57 | I'm Cora, a web front-end engineer, currently working on an AI project.
58 | 2. 你认为你会完成本次残酷学习吗？
59 | of course
60 |
61 | ## Notes
62 |
63 |
64 |
65 | ### 2024.12.10
66 |
67 | 阅读文档[Arbitrum 的简要介绍](https://docs.arbitrum.io/welcome/arbitrum-gentle-introduction)第一节
68 |
69 | ### 2024.12.11
70 |
71 | 查看如何使用 Solidity 智能合数字纸杯蛋糕自动售货机，尝试构建项目
72 |
73 | ### 2024.12.12
74 |
75 | 阅读文档如何在 Arbitrum 中估算 Gas
76 |
77 | ### 2024.12.13
78 |
79 | 阅读文档[Rollup，ZK Rollups 与 Optimistic，Arbitrum 的区别](https://cloud.tencent.com/developer/news/1003179)
80 |
81 | ### 2024.12.14
82 |
83 | 阅读文档[欺诈证明](https://docs.arbitrum.io/how-arbitrum-works/fraud-proofs/challenge-manager)
84 |
85 | ### 2024.12.15
86 |
87 | 阅读文档[非官方欺诈证明](https://www.theblockbeats.info/news/26507)
88 |
89 | ### 2024.12.16
90 |
91 | 阅读文档[Nitro vs. Classic](https://docs.arbitrum.io/how-arbitrum-works/why-nitro)
92 |
93 | ### 2024.12.17
94 |
95 | 阅读文档[Arbitrum 详解 - One、Nitro、Nova](https://community.dorahacks.io/t/arbitrum-one-nitro-nova/562)
96 |
97 | ### 2024.12.18
98 |
99 | 阅读文档[Inside Arbitrum Nitro](https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro)
100 |
101 | ### 2024.12.19
102 |
103 | 阅读文档[Arbitrum 的秘密武器：交互式欺诈证明](https://www.theblockbeats.info/news/26507)
104 |
105 | ### 2024.12.21
106 |
107 | 阅读文档[Arbitrum 创新的技术路线图](https://medium.com/offchainlabs/your-chain-your-rules-offchain-labs-technical-roadmap-to-fuel-arbitrum-innovation-f787f2e85966)
108 |
109 | 阅读文档[深度分析 Arbitrum 的繁荣生态](https://www.theblockbeats.info/news/35982)
110 |
111 | ### 2024.12.22
112 |
113 | 阅读文档[全览 Arbitrum 上百个生态项目：跨链、DeFi、基础设施、NFT](http://www.yuanli24.com/news/11836)
114 |
115 | 阅读文档[Arbitrum Orbit 生态探索：18 条 Orbit 链，加速以太坊生态多链时代](https://www.techflowpost.com/article/detail_15657.html)
116 |
117 | ### 2024.12.23
118 |
119 | 阅读文档[$ARB 代币：概念概述](https://docs.arbitrum.foundation/concepts/arb-token)
120 |
121 | 阅读文档[空投资格和分配规则](https://docs.arbitrum.foundation/airdrop-eligibility-distribution)
122 |
123 | 阅读文档[代币流通供应量](https://docs.arbitrum.foundation/token-supply)
124 |
125 | ### 2024.12.24
126 |
127 | 阅读文档[Arbitrum 原生代币 ARB 经济模型、价值主张和未来前景](https://foresightnews.pro/article/detail/28817)
128 |
129 | 阅读文档[Arbitrum 代币经济、机构成本、估值分析](https://foresightnews.pro/article/detail/28668)
130 |
131 | ### 2024.12.25
132 |
133 | 阅读文档[DAO 宪法](https://docs.arbitrum.foundation/dao-constitution)
134 |
135 | 阅读文档[DAO 术语表](https://docs.arbitrum.foundation/dao-glossary)
136 |
137 | ### 2024.12.26
138 |
139 | 阅读文档[如何提交 DAO 提案](https://docs.arbitrum.foundation/how-tos/create-submit-dao-proposal)
140 |
141 | 阅读文档[治理理念](https://docs.arbitrum.foundation/concepts/arbitrum-dao)
142 |
143 | 阅读文档[治理架构](https://docs.arbitrum.foundation/security-council-members)
144 |
145 | ### 2024.12.27
146 |
147 | 阅读文档[官方治理文档](https://docs.arbitrum.foundation/gentle-intro-dao-governance)
148 |
149 | ### 2024.12.28
150 |
151 | 阅读文档[治理论坛](https://forum.arbitrum.foundation)
152 |
153 | ### 2024.12.30
154 |
155 | 阅读文档[DAO 治理案例分析](https://foresightnews.pro/article/detail/45035)
156 |
157 |
158 |
--------------------------------------------------------------------------------
/CornellZheng:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # {cornellzheng}
55 |
56 | 1. Hello,大家好我是一位在校大学生，目前大四，步入web3这个圈子将近半年，希望能学习更多的知识，慢慢的步入这个行业
57 | 2. 我认为我会完成这次学习，一是我时间充裕，可以完成每日的学习任务，二是我对web3有着浓厚的兴趣。
58 |
59 | ## Notes
60 |
61 |
62 |
63 | ### 2024.12.10
64 |
65 | 笔记内容
66 |
67 | ### 2024.12.10
68 |
69 |
70 |
--------------------------------------------------------------------------------
/CornellZheng.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # {CornellZheng}
55 |
56 | 1. 大家好，我是一位大四学生，未来想要在web3行业有所作为，所以参加此次残酷共学
57 | 2. 我一定会完成此次共学！
58 |
59 | ## Notes
60 |
61 |
62 |
63 | ### 2024.12.10
64 |
65 | 今天的学习聚焦于Arbitrum这个以太坊扩容方案的基本原理。作为一个Layer 2解决方案，Arbitrum以其优化的性能和用户体验在区块链领域备受关注。初步了解后，我发现它的核心在于通过“Optimistic Rollup”技术来提高交易处理效率，同时保持去中心化和安全性。
66 |
67 | Optimistic Rollup的机制让我印象深刻，它通过将大量交易“打包”成一个数据块，并把这些交易的执行结果发送到以太坊主链上，从而大幅降低了链上操作的负担。这一方式避免了每笔交易都直接与主链交互，大幅提升了吞吐量。这种“乐观”态度的核心在于假设所有的交易都是有效的，只有在出现争议时，才需要验证具体交易。这种机制既减少了计算成本，又保持了去中心化的验证逻辑。
68 |
69 | 另一个引起我兴趣的是Arbitrum中的欺诈证明机制。这种机制允许任何用户对不正确的交易结果提出挑战。通过这种设计，即便有恶意行为者，整个系统的安全性仍然可以得到保障。学习这个概念时，我试图将其与以往接触过的区块链机制进行对比，发现它的灵活性和效率在技术上是一种创新。
70 |
71 |
72 | ### 2024.12.10
73 |
74 |
75 |
--------------------------------------------------------------------------------
/Helen2022a.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | # Helen
6 |
7 | 1. 自我介绍
8 | 拥有多年的web2后端开发经验，想开拓下web3领域
9 | 2. 你认为你会完成本次残酷学习吗？
10 | 会
11 |
12 | ## Notes
13 |
14 |
15 |
16 | ### 2024.12.13
17 |
18 | Arbitrum是一种基于Optimistic Rollup技术的以太坊Layer2 扩展解决方案，旨在解决以太坊上的拥堵和高gas费问题。
19 |
20 | Arbitrum是以太坊的辅助链。运行原理简单说就是Arbitrum 将很多交易一起打包，在Arbitrum链上先进行结算，然后再将交易数据提交给以太坊主链。
21 | Arbitrum采用了一种叫做Optimistic Rollup的技术，它可以将大量的交易打包成一个区块，并提交到以太坊主链上，只有在出现争议时才需要验证区块的正确性。这样可以大幅减少对以太坊主链的资源占用，提高交易吞吐量和速度。
22 |
23 | ARB是Arbitrum网络的原生Token，采用的标准是以太坊ERC-20，是Arbitrum网络的治理和激励Token，主要用于奖励验证节点、参与网络治理等。
24 | ARB只是一个治理token，不用于支付Arbitrum链上的任何费用。目前，用户在Arbitrum链上交互支付的Gas费仍是ETH
25 |
26 | ### 2024.12.14
27 |
28 | ## Rollup ZK Rollup
29 | Rollup的作用，就是将以太坊需要计算的内容复制，发送到以太坊之外连接的Layer2协议进行计算。然后，将结果信息压缩打包整理，重新发回到链上网络，从而提升以太坊的运行效率。而压缩包中，存有大量的签名确认信息。原先链上每笔交易一个Block里面只能有一个确认Sign签名，而现在这个块等于压缩了很多笔交易签名的VIP签名块。VIP一个过了，等于100个过了。这就间接将ETH的TPS大幅提升。
30 |
31 | Rollup Layer 2协议决定了以太坊的安全性
32 |
33 | ZK Rollups, ZKSnark 或者叫Zero Knowledge Rollups，是指一种利用零知识证明的密码学算法。
34 | ZKSnark的四大特点：
35 | 1. Zero Knowledge: 验证者无需看到交易所有数据
36 | 2. Succinct: 言简意赅的，简练的
37 | 3. Non-Interactive: 无需知道验证者是谁
38 | 4. Argument of Knowledge: 证明交易的真实性与正确性
39 |
40 | Zk Rollups的核心方法，即通过严谨复杂的验证算法，Layer 2协议中的验证者（ZkSnarker/ Validator ）来认证不同数据的真实性(Validity Proof)，从而将认证结果打包。
41 |
42 | 任何人都可以参与网络认证，成为认证者，所以，本质上来说，ZKSnark也是一种PoW共识机制的Layer 2协议。
43 |
44 | ## Optimistic Rollups Layer2
45 |
46 | 开始认为所有发送的交易都是值得信赖认证过的。Layer 2验证者需要先质押Token作为保证金，如果验证过程中，别人发现了有问题的打包，那么该验证者（Sequencer）将被罚款部分Token，并把其作为奖励给发现问题的人。
47 |
48 | 每次数据打包后，会有验证期，以供其他验证者检查是否有问题，是否需要重新退回打包。
49 |
50 | Optimistic Rollups也具有智能合约功能，可以拥有相应的治理Token
51 |
52 | Op Rollups与ZK Rollups方法本质的区别是，ZK所有人都可以参与通过PoW认证来参与认证，而OP里面更倾向于选择一组值得信赖的认证者，监督整个打包交易的过程。
53 |
54 | Optimism和Arbitrum本质上都是利用乐观型Optimistic Rollup模式的Layer 2协议项目
55 | Arbitrum在验证时，进行多轮fraud proofs.同时，Aribitrum的交易，并不在Layer1上进行执行，并且有自己的虚拟机，更加兼容ETH网络。
56 |
57 | 目前的ZK Rollups更适合Payment等需要快速交易的业务，算法稍复杂；而Optimistic类方法更适合Dapp开发与Defi业务，就是提币时间有点长
58 |
59 |
60 |
--------------------------------------------------------------------------------
/JacksonStack.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | # Kylin
6 |
7 | 1. 自我介绍
8 | web3开发新手；从hackquest了解到Ethereum，Solana，Arbitrum的开发；对Layer2更感兴趣。
9 | 2. 你认为你会完成本次残酷学习吗？
10 | Y
11 | ## Notes
12 |
13 |
14 |
15 | ### 2024.12.10
16 | **What:**
17 | Arbitrum 是一套旨在扩展以太坊的技术方案，允许用户以更低的费用和更快的速度执行在以太坊上的操作，如使用 Web3 应用和部署智能合约。
18 | Arbitrum 的旗舰产品是 Arbitrum Rollup，一个继承了以太坊安全性的 Optimistic Rollup 协议。
19 |
20 | **Why:**
21 | 以太坊本身的交易处理能力有限，每秒只能处理大约 20-40 笔交易（TPS），导致用户在交易量高峰时需要竞争交易被打包的机会，从而推高了交易费用。
22 |
23 | **How:**
24 | Arbitrum Rollup 链作为以太坊的一个子模块运行，不要求以太坊节点处理每笔 Arbitrum 交易，而是采用“乐观假设”机制，即默认 Arbitrum 上的活动遵循规则，除非有人提出异议。在争议中，两个验证者通过一个交互式的游戏来缩小争议到一个单一的计算步骤，该步骤在 L1 上执行，以证明诚实方说的是真话。
25 | Arbitrum Rollup 链的数据直接发布在以太坊上，确保了安全性和透明度。交易数据以压缩形式发布在 L1 上，进一步减少了交易的 L1 占用空间。
26 | Arbitrum 强调与以太坊的兼容性，用户可以使用他们喜欢的以太坊钱包，开发者可以使用他们喜欢的以太坊库和工具来构建和部署合约。Arbitrum 使用 Geth 的分叉（Nitro）来实现这一点，使得 Arbitrum 中运行的大部分代码与以太坊相同。
27 | Arbitrum 的最新技术堆栈 Stylus 保持了 Nitro 的以太坊兼容性，并增加了新功能，如使用 Rust、C++ 等编程语言编写高性能智能合约的能力。
28 | 对于不需要完全去中心化的应用程序，Arbitrum 提供了 AnyTrust 链，这种链在正常情况下将数据保存在链下，只有在争议发生时才会回到“rollup模式”，这样可以显著降低用户的费用。
29 | Arbitrum 技术支持多条链并行运行，目前以太坊主网上有两条 Arbitrum 链：Arbitrum One（Rollup 链）和 Nova（AnyTrust 链），用户和开发者可以根据他们的安全和交易成本需求选择。
30 |
31 | ### 2024.12.11
32 | Arbitrum 提供了多种 Layer 2 解决方案，以提高以太坊的可扩展性和降低交易成本：
33 |
34 | **Arbitrum One:**
35 | - Optimistic Rollup：通过在链下执行交易并仅将交易数据发布到以太坊主链上，实现高吞吐量。
36 | - Nitro 升级：引入 WASM 和 Geth，优化交易批处理和压缩，提升性能和降低成本。
37 |
38 | **Arbitrum Nova：**
39 | AnyTrust 技术：依赖数据可用性委员会管理链下数据，减少信任需求，提高用户体验，省去了长时间的提币等待期。
40 |
41 | **Arbitrum Stylus：**
42 | 新编程环境：支持使用 Rust、C++ 等语言开发智能合约，增强性能。
43 |
44 | **Arbitrum Orbit：**
45 | 自定义专用链：允许创建具有自定义隐私、权限和费用代币的专用链。
46 |
47 | ### 2024.12.12
48 | #### Rollup
49 | Rollup是一种技术，用于提高以太坊网络的交易处理能力（TPS）和降低交易成本。它通过将多笔交易在链下（Layer 2）进行批量处理，然后将结果（压缩数据）发布回以太坊主链（Layer 1）。这样可以减少主链的负担，提高效率。
50 |
51 | #### ZK Rollups
52 | ZK Rollups（Zero Knowledge Rollups）是一种使用零知识证明技术的Rollup方案。它允许在Layer 2上进行交易验证，而无需将所有交易数据发布到主链。
53 | 零知识证明允许验证者在不透露交易细节的情况下验证交易的有效性。
54 | ZK Rollups的特点包括：
55 | - Zero Knowledge：验证者无需看到交易所有数据。
56 | - Succinct：数据简洁。
57 | - Non-Interactive：无需知道验证者是谁。
58 | - Argument of Knowledge：证明交易的真实性与正确性。
59 |
60 | ZK Rollups适合需要快速结算的业务，如支付和交易所，但算法复杂，对应用开发有一定门槛。
61 |
62 | #### Optimistic Rollups
63 | Optimistic Rollups是一种Rollup方案，它默认所有交易都是有效的，除非有人提出异议。如果有人发现欺诈行为，可以通过挑战机制来解决。
64 | Optimistic Rollups的特点包括：
65 | - 乐观假设：默认所有交易都是有效的。
66 | - 挑战机制：如果发现问题，可以通过挑战来解决。
67 |
68 | Optimistic Rollups适合开发Dapp和DeFi应用，但提币回Layer 1的速度较慢。
69 |
70 | #### Arbitrum
71 | Arbitrum是一种基于Optimistic Rollups的Layer 2协议，它通过多轮欺诈证明来增强安全性，并拥有自己的虚拟机，更加兼容以太坊网络。
72 | Arbitrum与Optimism的主要区别在于它进行多轮欺诈证明，并且交易计算不依赖Layer 1。
73 |
74 | ### 2024.12.13
75 | 围绕 optimistic rollups，最主要的设计抉择是，如何解决争议。假设 Alice 断言 Rollup 会的运行会产生某个结果，而 Bob 不同意，那协议该如何定夺，选择谁提交的结果呢？
76 | 处理的方法基本可分两类：交互式证明，或者重执行交易。
77 | #### 交互式证明
78 | 交互式证明的思路是让 Alice 和 Bob 参与一个由 L1 合约引导的回合制协议，使用任何 L1 合约所需的最小开销来解决他们之间的分歧。
79 | Arbitrum 的方法基于对争议的剖析。如果 Alice 的断言涉及了 N 个执行步骤，那就让她曝光出两个各涉及 N/2 个步骤的断言，然后让 Bob 选择一个来挑战。这样一来，争议的规模就缩小了一半。
80 | 这个过程持续进行，每一回合都将争议的规模缩小一半，直到争议的范围变成一个执行步骤。注意，直到此时为止，L1 引导合约都不必考虑实际上执行了什么。仅当争议被缩小到单个执行步骤时，L1 引导合约才需要理解这一步要执行什么指令，以及 Alice 对该步的断言是否为真，以此解决争议。
81 | 交互式证明背后的关键原理是，如果 Alice 和 Bob 有所争议，Alice 和 Bob 应尽可能做链下的工作来解决争议，而不是让 L1 合约承担负担。
82 | **重执行交易**
83 | 让一个 Rollup 区块在区块内每一笔交易后附带一个状态哈希值断言。然后，在争议情形中，L1 引导合约将模拟一整笔交易的执行，看结果是否与 Alice 的断言一致。
84 | #### 优势
85 | - 效率更高
86 | 乐观情况下，一个区块只需要包含一个断言，空间占用小，节省成本。
87 | 悲观情况下，引导合约只需要执行一个步骤即可验证争议，速度快
88 | - 更高的交易级 gas limit
89 | 交互式证明的 gas limit 相较于 Ethereum 要大得多，重执行证明受限于 Ethereum 的 gas limit，可能没办法在一笔交易内模拟执行完
90 | - L2 上的合约大小没有限制
91 | 交互式证明不需要为 L2 合约在 Ethereum 上创建对应合约，所以不受限制；重执行模式的 gas limit 必须小于 Ethereum 合约的 gas limit（因为模拟执行的 gas limit 消耗更大）
92 | - 灵活性
93 | 举个例子，EVM 中新增指令，必要的功能无非是能在以太坊上验证一个单步执行的证据。而重执行模式就严格受限于 EVM
94 |
95 | ### 2024.12.14
96 | ChallengeManager 在 Fraud Proofs 系统中扮演着仲裁挑战游戏的角色，其主要功能和流程如下：
97 |
98 | 1. **区块挑战（Block challenge）**：
99 | - 挑战开始时，系统会对全局状态（包括区块哈希）进行二分查找（bisecting）。在对实际机器执行产生争议之前，争议会被缩小到单个区块。
100 | - 一旦挑战被缩小到单个区块，当前响应者可以调用 `challengeExecution`。这个过程类似于二分查找，响应者必须提供一个竞争性的全局状态和机器状态，但这些信息用于过渡到执行挑战阶段。
101 |
102 | 2. **执行挑战（Execution challenge）**：
103 | - 一旦挑战被缩小到单个区块，实际的机器执行可以被二分查找。一旦执行被缩小到单个步骤，当前响应者可以调用 `oneStepProveExecution`。
104 | - 响应者必须提供执行机器步骤的证明数据。如果执行该步骤的结果与之前断言的不同，当前响应者赢得挑战。
105 |
106 | 3. **通用二分协议（General bisection protocol）**：
107 | - `ChallengeLib` 辅助库包含一个 `hashChallengeState` 方法，该方法对一系列段哈希、起始位置和总段长度进行哈希处理，生成 `ChallengeLib.Challenge` 的 `challengeStateHash`。这些信息足以推断出每个段哈希的位置。
108 | - 挑战的“度”（degree）指的是段哈希的数量减一。一个段与下一个段之间的距离（以步骤计）是 `floor(segmentsLength / degree)`，对于最后一对段，`segmentsLength % degree` 被加到正常距离上，以确保总距离是 `segmentsLength`。
109 | - 挑战开始时只有两个段（度为一），这是断言者的初始断言。然后，二分游戏在挑战者的回合开始。
110 | - 在游戏的每一轮中，当前响应者必须选择一对相邻的段来挑战。通过这样做，他们对对手的主张提出争议，即从第一个段开始执行指定的距离（步数）将得到第二个段。此时，双方同意第一个段的正确性，但对第二个段的正确性持不同意见。
111 | - 响应者必须提供一个二分查找，起始段等于第一个段，但结束段与第二个段不同。这样做，他们将挑战分解为更小的距离，并轮到对手。
112 |
113 | 4. **赢得挑战（Winning the challenge）**：
114 | - 目前，赢得挑战并不是即时的。相反，它只是使当前响应者成为胜者的对手，并设置状态哈希为0。在那种状态下，该方没有任何有效的移动，因此最终会因超时而输掉。这样做是作为一种预防措施，以便如果挑战被错误地解决，还有时间诊断和修复错误，通过合同升级。
115 |
116 | ### 2024.12.16
117 | **Arbitrum One**
118 | - 架构：结合 L1 和 L2，L1 组件是 EthBridge，负责仲裁和维护收件箱与发件箱。AVM（Arbitrum 虚拟机）作为 L1 和 L2 之间的网关，ArbOS 在 AVM 上运行，确保智能合约在 L2 上执行。
119 | - 存款与提款：通过 L1 的 EthBridge 合约和 L2 的 Custom Gateway 合约进行代币的存入和提取。
120 | - Rollup 类型：多轮交互型 Rollup，通过争议断言（DA）推进虚拟机状态，押注机制和交互式纠纷解决协议确保正确性。
121 |
122 | **Arbitrum Nitro**
123 | - 技术升级：Nitro 是 One 的技术栈升级，包括证明程序、以 Geth 为核心、执行与证明分开、交互式欺诈证明的 Optimistic Rollup。
124 | - 无共识机制：Sequencer 公开操作，任何人都可以计算状态转移函数，降低成本。
125 | - Geth 重写：完全支持以太坊的数据结构、格式和虚拟机，提高兼容性。
126 | - 执行与证明分离：使用不同的代码实现执行和证明，提高效率。
127 | - 交互式欺诈证明：首创的证明系统，通过多轮交互确保安全性和正确性。
128 |
129 | **AnyTrust**
130 | - 数据可用性委员会：引入委员会存储 calldata 数据，减少主网上的数据量。
131 | - 最小信任假设：至少需要两名诚实成员保证协议运行。
132 | - Nova：基于 AnyTrust 技术的新链，专为成本敏感的用例设计，提供两种数据发布方式。
133 | **Arbitrum L3 战略**
134 | - Arbitrum Orbit：开发框架，允许创建和启动 L3 网络，定制链特性。
135 | - XAI：基于 Arbitrum Orbit 的首条 L3，专注于游戏和计算密集型 AI 模型。
136 | - BOLD：无需许可验证机制，最小化结算状态延迟。
137 | - Stylus：支持多语言构建应用程序的开源 SDK，降低 gas 成本，实现 EVM+ 兼容性。
138 |
139 | ### 2024.12.17
140 | #### Arbitrum Nitro
141 | **排序 确定性执行**
142 | 此图总结了 Nitro 中如何处理交易。
143 | 
144 |
145 | 用户事务在Nitro链中的处理流程：
146 | - 创建和签名事务：
147 | 用户创建事务，并使用他们的钱包进行签名。
148 | 用户将签名后的事务发送给Nitro链的Sequencer。
149 | - Sequencer排序：
150 | Sequencer接收事务，并将其按顺序排列。
151 | Sequencer的职责是将接收到的事务放入有序序列，并发布这个序列。
152 | - 状态转换函数：
153 | 排序后的事务逐一通过状态转换函数。
154 | 状态转换函数根据链的当前状态和下一个事务来更新状态。
155 | 状态转换函数会检测并丢弃任何无效的交易。
156 | - 确定性和结果：
157 | 状态转换函数是确定性的，意味着其行为仅取决于当前状态和下一个交易的内容。
158 | 任何知道交易序列的人都可以通过状态转换函数计算出相同的结果。
159 | - 节点操作：
160 | Nitro节点通过获取交易序列并在本地运行状态转换函数来操作。
161 | 这个过程不需要共识机制。
162 | - Sequencer发布序列：
163 | Sequencer通过两种方式发布序列：实时馈送和在L1以太坊上发布的批次。
164 | 实时馈送允许订阅者即时接收每个事务的通知。
165 | 这种即时通知提供了交易的“软确定性”，因为它依赖于Sequencer保持其承诺。
166 | - 硬性终局：
167 | Sequencer定期将交易批次压缩并发布到L1以太坊链上。
168 | 一旦这些以太坊交易在以太坊上具有最终确定性，记录的Layer 2 Nitro交易也将具有最终确定性。
169 | 这种最终确定性是“硬性终局”，因为交易的位置和结果是确定性的，任何一方都可以知道。
170 | - 数据压缩：
171 | Sequencer使用名为“brotli”的通用数据压缩算法在最高压缩设置下压缩其批次。
172 |
173 | ### 2024.12.18
174 | **核心的Geth**
175 | 
176 |
177 | Nitro 节点软件的结构可以被理解为由三个主要层组成：
178 |
179 | - 基础层（Geth核心）
180 | 这一层是 Geth 的核心部分，负责模拟 EVM 合约的执行和维护以太坊状态的数据结构。Nitro 将这部分代码编译为库，并进行了一些必要的小修改以添加钩子。
181 |
182 | - 中间层（ArbOS）：这一层是自定义软件，提供了与 Layer 2 功能相关的额外功能，包括解压和解析 Sequencer 的数据批次、核算 Layer 1 的 gas 成本和收集费用以补偿这些成本，以及支持跨链桥功能，比如从 L1 存入以太币和代币以及将它们提回 L1。
183 |
184 | - 顶层：主要由节点软件组成，主要来源于 Geth。这一层处理来自客户端的连接和传入的 RPC 请求，并提供运行与以太坊兼容的区块链节点所需的其他顶级功能。
185 |
186 | 由于顶层和底层严重依赖于 Geth 的代码，这种结构被称为 "geth sandwich"（Geth 三明治），其中 Geth 扮演面包的角色，而 ArbOS 是馅料。
187 |
188 | State Transition Function（STF）由底层的 Geth 层和中间层的 ArbOS 层的一部分组成。STF 是源代码中的一个指定函数，隐式包含了该函数调用的所有代码。
189 | STF 以收件箱中收到的交易字节作为输入，并可以访问以太坊状态树的可修改副本。
190 | 执行 STF 可能会修改状态，并在最后发出新区块的标头（以以太坊的区块标头格式），该区块将被附加到 Nitro 链中。
191 |
192 | ### 2024.12.19
193 | **执行与证明分开**
194 | Nitro 通过将执行与证明分开来解决实际 rollup 系统中的挑战：
195 |
196 | 1. **执行与证明使用相同源代码**：Nitro 对于执行和证明使用相同的源代码，但将它们编译成不同的目标格式，以适应不同的需求。
197 |
198 | 2. **编译执行代码**：在编译 Nitro 节点软件以供执行时，使用普通的 Go 编译器生成目标架构的原生代码，这会因不同的节点部署而异。
199 |
200 | 3. **编译证明代码**：对于证明部分，状态转换函数(State Transition Function, STF)的代码由 Go 编译器编译成 WebAssembly (WASM)，这是一种类型化、可移植的机器代码格式。然后，WASM 代码经过转换，形成 Nitro 所使用的 WAVM 格式。
201 |
202 | 4. **WAVM 的特点**：
203 | - **去除未使用特性**：WAVM 移除了 WASM 中一些 Go 编译器不生成的特性，确保这些特性不会出现在转换阶段。
204 | - **限制特定功能**：WAVM 不包含浮点指令，将浮点指令替换为对 Berkeley SoftFloat 库的调用，以减少架构间浮点不兼容性的风险。WAVM 也去除了嵌套控制流，将控制流指令转换为跳转。此外，WAVM 避免了执行时间可变的 WASM 指令，通过转换为使用固定成本指令的结构来实现。
205 | - **添加操作码**：WAVM 添加了一些操作码以实现与区块链环境的交互，例如读取和写入链的全局状态，从链的收件箱中获取下一条消息，或发出成功结束执行 STF 的信号。
206 |
207 | 5. **ReadPreImage 指令和 Hash Oracle 技巧**：
208 | - **ReadPreImage 指令**：这是一个新指令，它接受一个哈希 H 和一个偏移量 I 作为输入，并返回 H 原像中偏移量 I 处的数据字节。这个指令只能在原像公开已知且大小小于固定上限（约 110 KB）的上下文中使用，以确保安全。
209 | - **Hash Oracle 技巧**：这种技巧涉及存储数据结构的 Merkle 哈希，并依赖协议参与者存储完整的结构，从而支持通过哈希获取内容，这可以追溯到最初的 Arbitrum 设计。
210 |
211 | **Nova**
212 | 
213 | Nitro 是 One 的技术栈升级，并不是独立于 One 的网络，Nitro 升级后全称还是 Arbitrum One；而22年8月初上线的 Nova 是独立于 One 的网络。
214 | One/Nitro 跟 Nova 的区别：最核心的不同点是数据可用性，One 的数据可用性在链上（以太坊主网），Nova 的数据可用性在链下（数据可用性委员会 DAC）。
215 | Rollup 的本质是执行层的分离，把复杂运算转移到链下执行。
216 | One 将完整的数据集以 Calldata 的形式发布到以太坊主网，由于 Calldata 占用了一定的主网区块空间，此操作支付的 gas 费是 One 成本最大的组成部分。
217 | Nova 提供了 2 种数据发布方式，一种是像 Nitro 一样以 Calldata 的形式发布完整数据，另一种是发布 DACert 证明数据的可用性。
218 | Nova 的定序器将完整的数据集同时发送给所有 DAC 的委员会成员，委员会签名后把带有签名的证明返回给定序器，定序器收集到足够多的证明就能将它们聚合并创建有效的数据可用性证明（DACert），然后把 DACert 发布到主网。
219 | 如果定序器没有收集到足够多的证明，Nova 会回退到 Rollup 模式（以 Calldata 形式发布数据到主网）。
220 | 最简单的理解就是：One 把链下执行数据储存在以太坊主网，Nova 把数据存储在链下的数据可用性委员会。
221 | 相对于 One 而言，Nova 通过牺牲一定的安全性来提高性能，游戏社交类等需要高频交互的 Dapp 适合部署在 Nova 上。
222 |
223 | ### 2024.12.20
224 | **Your Chain, Your Rules**
225 | 核心理念：“Your Chain, Your Rules”：强调用户和开发者对区块链的控制权和自我治理能力。
226 | 技术路线图：
227 | - DevEx, UX, and Adoption
228 | - Stylus：允许使用 WASM 语言（如 Rust、C 和 C++）开发，超越了以太坊上构建的限制，支持 EVM 并降低 Gas 费用。
229 | - Arbitrum 纪念日更新：预计在 Arbitrum 纪念日发布重大更新，包括 Arbitrum Stylus 在 Arbitrum One 和 Nova 主网上的上线。
230 | - 去中心化：
231 | - BoLD（2024年下半年）：提高安全性和去中心化验证，使 Arbitrum 更接近 Stage 2 rollup。
232 | - 审查超时（2024年下半年）：限制反复审查或排序器离线对 Arbitrum 链的负面影响。
233 | - 去中心化排序器（预计2025年）：将交易排序的责任分配给更广泛的去中心化网络参与者。
234 | - 互操作性与可扩展性：
235 | - Arbitrum Orbit：允许开发者自定义他们的链，以适应特定用例。
236 | - 快速提现（2024年第三季度）：使 AnyTrust 链能够绕过确认延迟，实现快速结算。
237 | - 链集群（2025年）：通过允许多个 Orbit 链紧密对齐，减少跨链通信时间。
238 | - 性能与效率：
239 | - 多客户端支持（2025年上半年）：优化区块生产速度，降低硬件成本，提高吞吐量。
240 | - 自适应定价（2025年上半年）：动态设置 Gas 限制，提高资源利用效率。
241 | - 零知识证明：
242 | - ZK+Optimistic 混合证明：探索将 ZK 证明集成到 Arbitrum 链中，提供即时确认声明的可选快速路径。
243 | - 未来展望：Offchain Labs 致力于在问题出现之前创造解决方案，推动区块链技术的边界。
244 |
245 | ### 2024.12.22
246 | **Arbitrum应用生态**
247 | 
248 | Arbitrum 的应用程序生态系统可以分为两大类：DeFi 和消费者应用程序。在这些生态系统中构建的项目已经采用 Arbitrum 来获得粘性用户群和从以太坊继承的强大安全保证。
249 | **Defi**
250 | 
251 | DeFi 生态系统已经存在大量竞争，并以其 DEX、借贷和永续合约为基础。
252 |
253 | ### 2024.12.23
254 | 项目总数与分类：
255 | Arbitrum 生态门户共列出了 170 多个项目，涉及钱包、交易所、支付网关以及桥和跨链项目约 60 个；DeFi 应用近 40 多个，主要分布在衍生品、AMM 和收益优化方面；NFT 市场 3 个，其中 TreasureDAO 占据主导角色；支持 Arbitrum 的工具、基础设施以及节点提供方约 30 个。
256 | The Arbitrum Odyssey 生态采用计划：
257 | 56 个项目参与生态采用计划，包括 Yield Protocol、Hashflow、Aboard Exchange、tofuNFT、Uniswap、ApeX、1inch、Yin Finance、DODO、Swapr、TreasureDAO、BattleFly、Ideamarket 和 SushiSwap 等，用户通过体验这些项目收集 NFT 以获得最终设计的 arbi-verse NFT。
258 | 出入金/钱包/交易所：
259 | 支持 Arbitrum One 主网的中心化加密交易所包括 Bitget、币安、Bybit、Crypto.com、FTX、火币、KuCoin、MEXC、OKX 等，支持 ETH 或 USDT 的充提。
260 | 支持 Arbitrum One 主网的钱包包括 BitKeep、Coinbase Wallet、MetaMask、DeBank、imToken、MathWallet、Trust Wallet、Zapper、Zerion 等 24 个。
261 | 桥/跨链项目：
262 | 包括 Arbitrum One Bridge（官方桥）、Across Protocol、BoringDAO、Bungee、Multichain、Celer cBridge、Composable Finance Mosaic、Connext、deBridge、Hop、LI.FI、pNetwork、RenBridge、Router Protocol、Rubic、SOCKET、Stargate、Synapse Protocol 等，支持不同网络间的资产转移和兑换。
263 | DeFi 应用：
264 | 包括衍生品、AMM 和收益优化项目，如 SushiSwap、1inch、Aave、Curve、dForce、Uniswap、Abracadabra、Balancer、Saddle Finance、Beefy Finance、DODO、MCDEX、Yearn Finance、Hashflow 等。
265 | NFT 市场：
266 | 主要包括 Stratos、tofuNFT、TreasureDAO，其中 TreasureDAO 旗下元宇宙游戏 Bridgeworld 内的 NFT 系列热度偏高。
267 | 工具/基础设施支持：
268 | 包括 Band Protocol、Biconomy、BlockVision、Chainlink、Covalent、DefiLlama、Etherscan、Nansen、Snapshot、Tenderly、The Graph、Truffle Suite 等二十多个。
269 | 节点提供方：
270 | 包括 Alchemy、Ankr、DataHub、GetBlock、Infura、Moralis 和 QuickNode。
271 | ### 2024.12.25
272 | $ARB代币是一种ERC-20治理代币，持有者可以通过它参与Arbitrum DAO的链上治理协议。这意味着持有者可以对影响Arbitrum One和Arbitrum Nova链的提案进行投票，包括链的升级和DAO金库资金的使用。
273 | Arbitrum DAO负责管理宪法中定义的治理协议以及DAO所管理的技术，包括Arbitrum One和Arbitrum Nova链及其底层协议。
274 | 持有的$ARB代币越多，投票的影响力就越大，因为Arbitrum DAO的智能合约实现了代币加权投票，即投票的力量由选民钱包中的代币数量决定。
275 |
276 | $ARB代币可以委托给其他钱包，这意味着即使您没有时间定期审查和讨论提案，也可以通过委托您的投票权来参与治理。
277 |
278 | $ARB代币的初始供应量为1000亿枚，新$ARB代币最多可以以每年2%的供应量速度铸造，第一批铸造活动于2024年3月15日成为可能。
279 | Arbitrum DAO通过宪法提案执行$ARB代币的铸造活动，并且随着$ARB代币的空投，Arbitrum的治理权正式转移到Arbitrum DAO手中，标志着向去中心化治理的转变。
280 |
281 | 要参与Arbitrum DAO治理，您需要持有$ARB代币的以太坊钱包，并可以通过连接到Tally的Arbitrum DAO页面进行委托投票。
282 | ### 2024.12.26
283 | Arbitrum 经济模型
284 | $ARB 供应和分配概览
285 | $ARB代币的总供应量初始上限为100亿枚，其中17.53%分配给Offchain Labs投资者，1.13%分配给Arbitrum生态系统中的DAO，11.62%通过空投分配给Arbitrum平台用户，42.78%分配给Arbitrum DAO国库，26.94%分配给Offchain Labs团队、未来团队和顾问。
286 | 治理方式
287 | Arbitrum推出了自执行DAO治理模型，$ARB代币持有者可以对Arbitrum One和Arbitrum Nova网络的治理提案进行投票。
288 | 治理是自执行的，意味着投票结果将直接影响并执行链上决策，无需中介。
289 | ARB 的价值主张空投认领规则和方法
290 | 用户空投资格
291 | DAO 空投标准和分配
292 |
293 | ### 2024.12.27
294 | **Arbitrum DAO术语表**
295 | $ARB：Arbitrum的治理代币，是Arbitrum One链上的原生ERC-20代币。持有$ARB代币的人可以参与Arbitrum的链上治理。
296 | $ARB反向网关：一系列智能合约，负责在Arbitrum One和以太坊之间桥接$ARB代币。
297 | 活跃验证者：一个质押的验证者，它提出可争议的断言以推进Arbitrum链的状态或挑战其他人断言的有效性。
298 | 空投：一种将代币分发到合格钱包地址的机制，通常基于链上活动。
299 | Arbitrum AnyTrust链：实现Arbitrum AnyTrust协议的Arbitrum链。
300 | Arbitrum AnyTrust协议：一种Arbitrum协议，通过一个名为数据可用性委员会（DAC）的许可方集合来管理数据可用性。
301 | Arbitrum链：在Arbitrum协议上运行的区块链，与EVM兼容，使用底层EVM链（例如，以太坊）进行结算和简洁的欺诈证明。
302 | Arbitrum链所有者：有能力升级Arbitrum核心协议合约和设置各种系统参数的实体。
303 | Arbitrum DAO：全球$ARB代币持有者和代表组成的社区，负责治理Arbitrum One链、Arbitrum Nova链、Arbitrum DAO宪法和安全委员会。
304 | Arbitrum DAO国库：存在于Arbitrum One链上的智能合约，包含由Arbitrum DAO集体控制的代币。
305 | Arbitrum改进提案（AIP）：由Arbitrum DAO宪法定义的治理提案，分为宪法AIP和非宪法AIP。
306 | Arbitrum Nitro：当前Arbitrum技术栈；运行Geth的分支，并使用WebAssembly作为其底层虚拟机。
307 | Arbitrum Nova：第一个在以太坊主网上运行的Arbitrum AnyTrust链，引入了更便宜的交易。
308 | Arbitrum One：第一个在以太坊主网上运行的Arbitrum Rollup链，完全无需信任。
309 | Arbitrum Rollup链：实现Arbitrum Rollup协议的Arbitrum链。
310 | Arbitrum Rollup协议：一种无需信任、无需许可的Arbitrum协议，使用其底层基础层进行数据可用性，并继承其安全性。
311 | 子链：一个结算到底层父链的Arbitrum链。例如，Arbitrum One和Arbitrum Nova是 Ethereum的子链。
312 | 可申领空投期：合格$ARB代币接收者能够申领其代币的时间周期。
313 | 宪法AIP：与非宪法AIP相比，要求更严格的提案，需要更长的延迟期才能生效。
314 | 核心治理者：负责创建宪法AIP的治理合约。
315 | 数据可用性委员会（DAC）：一个许可方集合，负责在Arbitrum AnyTrust协议链中执行数据可用性。
316 | 去中心化应用（dApps）：结合基于区块链的智能合约与前端用户界面的应用。
317 | 代表：能够对Arbitrum治理提案进行投票的一方，可以是$ARB代币持有者或被其他$ARB代币持有者委托投票权的人。
318 | 紧急行动：安全理事会在紧急情况下使用的一种特定类型的治理行动，例如修复关键漏洞。
319 | 以太坊共识层（CL）：促进以太坊Layer 1（L1）网络的质押、点对点共识、区块创建和证明。
320 | 以太坊执行层（EL）：促进以太坊Layer 1（L1）网络的智能合约逻辑和执行。
321 | 排除地址：ARB持有者可以将其投票权委托给这个特殊地址，以便在提案的法定人数计算中不被包括。
322 | 基金会归属钱包：存储Arbitrum基金会代币的智能合约钱包；代币在4年的时间里线性归属。
323 | 治理：决策制定的方式，传统web2技术的治理依赖于董事会遵循信任社会契约，而web3技术的治理依赖于使用无需信任智能合约的去中心化自治组织（DAO）。
324 | 治理提案：改变Arbitrum DAO治理协议某些方面的提案。
325 | 治理代币：允许代币持有者对治理提案进行投票的特定类型的代币。
326 | 不可变：在以太坊的背景下，不可变性指的是无法改变区块链中记录的数据。
327 | Layer 1 (L1)：以太坊网络的基础协议和底层区块链。
328 | Layer 2 (L2)：建立在以太坊Layer 1（L1）基础协议之上的无需信任的扩展解决方案。
329 | 机制设计：设计协议或机制的过程，以激励特定行为。
330 | 多签名钱包：需要多个私钥签名的钱包。
331 | 节点运营商：在以太坊/Arbitrum生态系统中运行核心协议软件的任何人。
332 | 非宪法AIP：Arbitrum DAO治理提案的两种类型之一。
333 | 链下治理：通过社会共识和链下提案执行的治理。
334 | 链上治理：由智能合约实现的治理，允许DAO成员通过治理提案决定DAO如何分配资源和更新协议。
335 | 乐观汇总协议：设计用于通过使用基础层进行数据可用性并将计算卸载到链下节点来扩展以太坊基础层吞吐量的Layer 2（L2）协议。
336 | 父链：作为一条或多条Arbitrum链（即子链）的结算层的EVM兼容链。
337 | 逐步去中心化：随着时间的推移逐渐增加系统去中心化的过程。
338 | 提案等待期：在治理提案被接受后开始的合同强制延迟期。
339 | Prysm：为以太坊Layer 1（L1）提供动力的共识层客户端。
340 | 法定人数：治理提案通过所需的最低票数。
341 | 安全理事会：由持有12个成员多重签名钱包私钥的12个实体组成的委员会。
342 | 安全理事会队列：安全理事会的12名成员被分成两个六人队列。
343 | 种子短语：用于恢复以太坊钱包私钥的高敏感性、确定性词汇序列。
344 | 序列器：被赋予在固定时间窗口内重新排序快速收件箱中的交易的实体。
345 | 智能合约：存储和在以太坊区块链上执行的自执行代码。
346 | Snapshot投票：代表可以链下投票的机制。
347 | 标准代币网关：负责在以太坊和Arbitrum链之间桥接ERC20代币的一系列智能合约。
348 | Tally：用于与Arbitrum治理合约交互的Web界面。
349 | Arbitrum基金会：由Arbitrum DAO治理的法律实体。
350 | Arbitrum国库代币：由Arbitrum DAO国库拥有的$ARB代币。
351 | Arbitrum DAO宪法：规定Arbitrum DAO运作规则、程序和社区价值观的正式文件。
352 | 时间锁合约：限制在指定未来时间之前采取行动的智能合约。
353 | 代币分配合约：负责持有和分配空投$ARB代币的智能合约。
354 | 代币加权治理：一种治理系统，其中投票权重与治理代币的所有权成正比。
355 | 透明度报告：解释采取了哪些行动以及为什么的报告。
356 | 国库治理者：负责创建非宪法AIP的治理合约。
357 | 无需信任：指系统能够在不依赖中央权威或中介的情况下运作。
358 | 未认领空投代币：未被潜在所有者认领的可申领$ARB代币。
359 | 可投票代币：除了Arbitrum DAO和Arbitrum基金会拥有的代币之外的所有$ARB代币。
360 | 投票期：Arbitrum改进提案（AIP）提交成功后，Arbitrum DAO成员可以投票支持或反对的14-16天期间。
361 |
362 | ### 2024.12.28
363 | 治理架构：阅读 [安全理事会成员](https://docs.arbitrum.foundation/security-council-members)
364 | Arbitrum DAO是一个建立在以太坊区块链上的去中心化自治组织，它通过社区驱动的治理机制赋予$ARB代币持有者提出和投票决定组织及其技术变化的能力。其治理智能合约部署在Arbitrum One rollup链上，这是一个第2层扩展解决方案，旨在提升以太坊的可扩展性。代币持有者使用$ARB代币对提案进行投票，其投票权重与他们持有的代币数量成正比。Arbitrum DAO还设有一个内置金库系统，用于资助组织的持续开发和维护，代币持有者可以对金库资金的使用提出建议并进行投票。此外，DAO内置了一个安全委员会，负责确保DAO及其链的安全性和完整性，并在安全紧急情况下迅速采取行动，绕过常规投票过程。安全委员会成员由DAO成员通过半年一次的选举产生。
365 |
366 | ### 2024.12.29
367 | 如何提交 DAO 提案
368 | 先决条件：
369 | 提交提案需要拥有一定数量的可投票代币，对于Snapshot轮询的温度检查需要至少500,000个代币，而对于Tally链上提案则需要至少1,000,000个代币。
370 | 提案类型：
371 | 确定你的提案是宪法性（Constitutional）还是非宪法性（non-Constitutional）提案，前者涉及修改宪法或AIP-1的文本、程序，或需要链上所有者权限的行动；后者则包括请求资金/赠款或提供社区指南和信息的提案。
372 | 提案结构：
373 | 包括摘要、动机、理由、关键术语、规格、实施步骤、时间轴和总成本等部分。如果提案未通过，重新提交时还需包括先前提案的链接、未通过的原因以及对提案所做的更改。
374 | 提案前开发： 如果提案需要代码更改，应包括通过提案后将执行的代码。
375 | 第1步：进行正式的温度检查：
376 | 在DAO治理论坛上创建新帖子并使用模板提交提案，然后在Snapshot上创建一个为期一周的投票来衡量社区对提案的兴趣。
377 | 第2步：使用Tally提交链上提案：
378 | 如果你的钱包可以代表至少1,000,000个代币，你可以在Tally上创建链上提案，选择目标调控器（Arbitrum Core或Arbitrum Treasury），添加提案名称、描述和行动，预览并提交提案。
379 | 提案通过条件：
380 | 提案通过需要赞成票多于反对票，并且投赞成票的总票数至少达到可投票代币的一定百分比（宪法AIP为5%，非宪法AIP为3%）。
381 | 重要说明：
382 | 安全理事会有权执行紧急和非紧急行动，无需经过提案过程。提案通过所需的支持门槛可能因提案类型和宪法中规定的法定人数要求而异。你可以将投票权委托给其他地址，即使没有足够的代币提交链上提案。
383 |
384 | ### 2024.12.30
385 | Arbitrum DAO 治理案例： Arbitrum赠款战争
386 | Arbitrum社区通过DAO的形式，让ARB代币持有者参与到治理提案的投票中，共同决定资金的分配和生态的发展方向。社区成员通过Snapshot和Tally平台进行投票。5000万ARB代币被分配给57个项目，这些项目大多是Arbitrum上的原生项目。资金分配过程中，超过5000万ARB的申请量意味着需要根据赞同票数量进一步筛选。
387 | 原生项目如Camelot、JonesDAO、Dopex、GMX获得了最多的支持，而与Arbitrum生态相关度不高或争议较大的项目如Lido未能获得通过。项目获得的支持票数和TVL（总锁定价值）等指标被用来作为资金分配的依据。
388 | Arbitrum社区多次呼吁开展激励计划，最终在短时间内得到了推进和落实。激励计划工作组由多个项目团队成员组成，他们共同推动了激励计划的实施。
389 | Arbitrum的提案生效通常需要经过Snapshot上的民意调查投票和Tally上的链上投票两轮投票。本次激励计划的资金已经由一个单独的提案通过Tally链上投票后分配给多签地址，显示了DAO治理的高效性。工作组根据项目在Arbitrum上运行的时间、TVL、30天交易量等条件，将赠款分为不同类别，以激励项目对生态的贡献。
390 |
391 |
392 |
--------------------------------------------------------------------------------
/LunaWang5209:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # 古忆
55 |
56 | 1. 币圈老韭菜
57 | 2. 你认为你会完成本次残酷学习吗？会
58 |
59 | ## Notes
60 |
61 |
62 |
63 | ### 2024.12.10
64 |
65 | 笔记内容
66 |
67 | ### 2024.12.10
68 |
69 |
70 |
--------------------------------------------------------------------------------
/Marcus.md:
--------------------------------------------------------------------------------
1 | timezone
2 | Asia/Shanghai
3 | 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 时区请参考以下列表，请移除 # 以后的内容
4 |
5 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
6 |
7 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
8 |
9 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
10 |
11 | timezone: America/Denver # 山地标准时间 (UTC-7)
12 |
13 | timezone: America/Chicago # 中部标准时间 (UTC-6)
14 |
15 | timezone: America/New_York # 东部标准时间 (UTC-5)
16 |
17 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
18 |
19 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
20 |
21 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
22 |
23 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
24 |
25 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
26 |
27 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
28 |
29 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
30 |
31 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
32 |
33 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
34 |
35 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
36 |
37 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
38 |
39 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
40 |
41 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
42 |
43 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
44 |
45 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
46 |
47 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
48 |
49 | Marcus
50 | hi, 大家好。我是 Marcus,在负责 OP 中文力量，在 Optimism 的研究中，也看到了 arbitrum 的很多治理研究和机制，我想系统的学习一下 arbitrum，这样子便于交流和了解，互相学习
51 |
52 |
53 |
54 | ### 2024.12.10
55 |
56 |
57 |
58 | ### 简单概念
59 | Arbitrum 是一个 Layer2 网络，用的是 Arbitrum Rollup 的机制（俗称欺诈证明，即代表如果你的交易内有欺诈交易，只要你被证明是虚伪交易，那么你质押的一半资产要给到挑战者）
60 |
61 | ### 为什么 L2 比 L1 的 Tps 要快很多
62 | 其实这点我理解下来比较简单，L2 相当于对交易进行打包，一个包里面包含数百上千笔交易，每次 L1 只处理一个包，这样的效率就提升了几百上千倍，这样子 L2 的 Tps 就会高很多，并且 L2 的共识层也没有改变，还是 L1
63 |
64 | ### Arbitrum 的兼容性如何
65 | Arbitrum 的创建以以太坊兼容性为首要任务。这意味着用户可以将 Arbitrum 与所有他们喜欢的以太坊钱包一起使用；开发人员可以使用所有他们喜欢的以太坊库和工具构建和部署合约；事实上，大多数时候，使用 Arbitrum 的体验与使用以太坊的体验相同（重要的一点是它更便宜、更快）。
66 |
67 | 为了实现这种程度的以太坊兼容性，我们进行了大量开发。但其核心是：Arbitrum 本身使用了Geth的一个分支（这是使用最广泛的以太坊实现），并对其进行了修改，以将其转变为无需信任的第 2 层。这意味着在 Arbitrum 中运行的大部分代码与在以太坊中运行的代码相同。我们将这种尖端方法称为 Nitro（开发人员可以在此处查看代码库）
68 |
69 | ### Arbitrum 和 Optimism 有什么不同
70 | Optimism 和 Arbitrum 是目前最大的两个以太坊 Layer-2 解决方案，都使用了 Optimistic Rollup 技术来拓展以太坊网络
71 |
72 | 尽管 Arbitrum 和 Optimism 都被称为 Optimistic Rollup，二者仍有一些本质上的区别。
73 |
74 | 其一，二者验证交易所使用的争端解决程序不同。Optimism 使用的是在 Layer-1 上执行的单轮欺诈证明，而 Arbitrum 使用链下执行的多轮欺诈证明。相比单轮欺诈证明，Arbitrum 的多轮欺诈证明更加便宜和高效，但是由于是链下执行，也会有一定的安全性风险
75 |
76 | 其次，虽然 Optimism 和 Arbitrum 都兼容 EVM，但 Optimism 使用的是以太坊的 EVM，而 Arbitrum 使用自己的 Arbitrum 虚拟机（AVM）。这导致 Optimism 只有 Solidity 编译器，而 Arbitrum 支持所有 EVM 编译语言（Vyper、Yul 等）
77 |
78 | 验证机制：Arbitrum 使用了一种名为”Fraud Proof”的验证机制来确保交易的安全性。在这个验证机制中，一些特殊的用户（称为验证人）会对提交的交易进行验证，并在需要时向以太坊主链提交证明，以保证交易的正确性。相比之下，Optimism 使用了一种名为”Fraud Prover”的验证机制。在这个验证机制中，一些特殊的用户（称为验证人）会在提交的交易被打包到区块之前，先验证其正确性，以避免在之后需要提交证明。
79 | 智能合约执行：Arbitrum 使用了一种名为”Arbitrum VM”的虚拟机来支持智能合约的执行。这个虚拟机与以太坊主链的虚拟机（EVM）相似，但是具有一些特殊的优化，可以实现更高的执行效率。Optimism 使用了一种名为”Optimistic Virtual Machine”（OVM）的虚拟机来支持智能合约的执行。OVM 与 EVM 兼容，但是可以通过一些优化来实现更高的执行效率。
80 | 治理模型：Arbitrum 和 Optimism 的治理模型也有所不同。在 Arbitrum 中，所有的验证人都可以参与投票，决定哪些交易可以被打包到区块中。在 Optimism 中，只有一部分特殊的用户（称为”sequencer”）可以打包交易到区块中，并决定区块的生成。 Arbitrum 和 Optimism 都使用了欺诈式证明（Fraud Proof）机制来确保交易的安全性。 欺诈式证明是一种可验证的证据，用于证明在区块链网络中发生了欺诈行为。在使用欺诈式证明的机制中，如果一个用户提交了一个不合法的交易或区块，其他用户可以使用欺诈式证明来证明这一不合法行为，并通过提交欺诈证明来获得相应的奖励。
81 |
82 | ### 生态方向
83 | Arbitrum 更偏向于 DeFi 以及 GameFi 方向，Optimism 更偏向公共物品和基础建设，同时, Optimism 的未来版图是超级链网络，即打造一体化和互通化的 l2，而 arbitrum 更偏向于应用层面
84 |
85 |
86 | ### 欺诈证明
87 | 如果 arb 使用的是欺诈式证明，几天后发现是诈骗，假如资金已经被转出谁来赔偿这个损失？
88 | 在 Arbitrum 网络中，如果一个交易被验证人通过并打包进区块，而后被证明是欺诈行为，那么验证人将会失去相应的奖励，并需要支付一定的惩罚金。惩罚金将会被分发给提交欺诈证明的用户，作为他们的奖励。 但是，如果已经发生诈骗或其他不良事件，导致用户的资金被盗或损失，这并不属于 Arbitrum 网络本身的责任范畴。Arbitrum 网络提供的是一种安全性较高的交易验证机制，可以有效地减少欺诈行为的发生。但是，由于区块链技术的本质特点，一旦交易被确认，就无法被撤销或更改。因此，在进行交易时，用户需要自行承担风险，并确保自己的资产安全。
89 |
90 |
91 |
92 |
93 | ### 2024.12.11
94 |
95 | ### Arbitrum DAO
96 | Arbitrum DAO 也是采取 Pos 治理，即你持有的 arb 越多，你的投票权越大，arb 更偏向于社区驱动的方式来治理，但内部有一个安全委员会，为了防止一些治理攻击的方式出现，安全委员会是一组实体，负责确保 DAO 及其链的安全性和完整性。根据《宪法》规定，委员会可以绕过缓慢的投票程序，在出现安全紧急情况时迅速采取行动。安全委员会成员由 DAO 通过半年选举产生，安全委员会有 12 名成员，如果发生紧急问题，他们可以采取紧急行动，9/12 的投票即可直接行动
97 |
98 | ### Arbitrum 如何投票的
99 | Arbitrum 的投票模式其实和大部分 DAO 都差不多，显示温度检查，一般是在论坛发布提案，然后到 Tally 上发起正式提案，通过即代表提案开始执行
100 | Arb 同样对提案进行了分级，
101 | Arbitrum 改进提案 (AIP)是由 Arbitrum DAO 成员提交的提案，提议对 Arbitrum 生态系统进行更改。AIP 有两种类型：宪法和非宪法：
102 |
103 | 宪法 AIP 是指修改宪法或 AIP-1 的文本或程序、在任何链上安装或修改软件、或在任何链上采取任何需要“链所有者”许可的行动。
104 | 非宪法 AIP 是所有其他 AIP，例如那些请求资金/补助金或向社区提供一般指导或信息的 AIP。
105 | 简单来说，一些动到协议本身的提案，如通胀系数，协议的一些新增组件，那么都是宪法 AIP，需要通过链所有者许可，需要再进行一次评判，其他的申请 Grants 和社区指导的提案就不是宪法 AIP
106 |
107 | 整个 AIP 投票过程（包括所有七个阶段）从第一阶段的温度检查开始通常需要 37 天（宪法 AIP）或 27 天（非宪法 AIP）。此过程旨在进行彻底的考虑和投票，确保每个人都有公平的机会表达他们的意见和担忧。
108 |
109 | ### Arbitrum 是如何分配 Grants 给社区的
110 | Arbitrum 的预算是根据 AIP 来分配的，包括基金会自己的预算也要通过 AIP 来提出，然后 Arb 的 Grants 发放更多像是 DAO 内的委员会形式，形成了如 LTIPP 的激励计划(4500W arb),GCP(游戏催化剂)等分类别的资助委员会，一般资助委员会由几人组成，然后定期审阅项目并批款，同时也有一些总结报告
111 | 如：https://forum.arbitrum.foundation/t/long-term-incentives-pilot-program/20223
112 |
113 | ### Arbitrum 和 Optimism 的治理不同
114 | Arb 的治理模型为 DAO、委托和质押模式
115 | Arbitrum 由Arbitrum DAO治理，该 DAO 由 $ARB 代币持有者组成，他们可以提议并投票决定网络技术变更。代币持有者可直接参与治理，也可委托代表。Arbitrum DAO 最近通过了一项提议，引入 $ARB 代币质押，将其从纯治理代币转变为双重功能代币。未来，Arbitrum 的治理将基于质押 ARB 代币（$stARB）。这一变化旨在增加 $ARB的价值和提高治理参与度。
116 |
117 | Arbitrum 希望快速提高治理参与度，因为目前只有约 10% 的 $ARB 流通量用于治理。Arbitrum DAO 通过智能合约实现，负责管理内置的财库系统。它还设有安全委员会，可在紧急情况下升级协议。安全委员会是治理结构的关键部分，负责在这些关键情况下做出决策，成员由 Arbitrum DAO 选举产生。Arbitrum 的治理结构是偏向财阀制的，因为$ARB代币持有者是系统的主要决策者。
118 |
119 | OP 的治理模型为二院制
120 | 乐观采用非财阀治理系统，防止被单一实体或小群体控制。这意味着代币持有者不是协议升级、资源分配和创新的唯一决策者。即使积累大量OP治理代币，也无法轻易控制网络价值，因为乐观采用了两院制支架，其公民屋与代币屋相互制衡。
121 |
122 | 乐观集体是一个实验性的治理团体，治理细化不断迭代，因为他们认为长期愿景有时可能与短期价值相互冲突。
123 |
124 | 代币由 OP 治理代币持有者组成，他们可以直接投票或将投票权委托给信任的代表。公民屋则由在乐观生态象征的个人组成，公民由灵魂绑定的 NFT 拯救公民屋实行一人一票制，推动了民主进程。
125 |
126 | 代币屋负责协议升级和激励投票，而公民屋主要管理复古资助（主要项目性公共项目资助），确保协议追求长期目标，防止被实体特定控制。两院相互制，可以衡一院的核心职责被另一院否决。
127 |
128 |
129 | ### Arb 和 OP 谁的治理模型更好
130 | 这个说不上谁好谁坏，我整体的感觉是 Arb 更偏社区化一些，表面上没有明显的精英领导（当然背后也肯定有 arb 基金会或者安全委员会去推动），OP 更多的是社区+精英化治理的方式，二院的对抗，token house 为下议院，citizen house 为上议院，两院之间相互制衡
131 | 但是我目前感觉 arb 的治理偏社区化可能会导致一些治理资金的浪费，比如 treasuryDAO 的游戏激励计划，把整个 arb 都带向了游戏化的路线，但是游戏这个赛道又没起来，而 OP 感觉背后有 OP 基金会和 Coinbase 的助推，看起来更正规和精英化一些，也更偏向以太坊的核心层的感觉，arb 对比下来更社区化，当然也更分散，同时有一个问题就是社区化引导可能带来试错成本比较高，从而导致资金的浪费
132 |
133 | ### 2024.12.12
134 | ### 如何评价 L2 的去中心化程度
135 | Arb 和 OP 目前都是基于 Rollup 实现的，但是 L2 如何实现去中心化，把整个智能合约交给社区来管理，并且保持安全性的情况下达到去中心化运作，我这里看到 L2beat 提出了一套评估 Rollups 成熟度的框架，也是 Rollups 项目逐渐走向去中心化的关键
136 |
137 | 在区块链技术不断发展的背景下，rollup 已成为一种有前途的解决方案，可以在信任最小化的情况下扩展以太坊。然而，这些系统的开发通常涉及一个集中控制阶段，通常被称为“训练轮”，允许在受控环境中进行系统更新和错误修复。
138 |
139 | 虽然在早期阶段这些辅助工具必不可少，但最终还是应该移除它们，这样 Rollup 才能完全继承基础层的安全属性。为了引导这一转变，我们引入了一个新框架，该框架受到Vitalik 提出的里程碑的启发，根据 Rollup 对辅助工具的依赖程度，将 Rollup 分为三个不同的阶段：
140 |
141 | 第 0 阶段 — 全面训练：在此阶段，rollup 由操作员有效运行。不过，有一个源可用软件，可以根据 L1 上发布的数据重建状态，用于将状态根与提议的根进行比较。
142 | 第 1 阶段 — 有限的训练轮：在此阶段，rollup 过渡到由智能合约管理。但是，可能会保留一个安全委员会来解决潜在的错误。此阶段的特点是实施功能齐全的证明系统、分散欺诈证明提交，并提供无需运营商协调的用户退出。由多元化参与者组成的安全委员会提供了安全网，但其权力也带来了潜在风险。
143 | 第 2 阶段 — 无需训练：这是 Rollup 完全由智能合约管理的最后阶段。此时，防欺诈系统无需许可，如果出现不必要的升级，用户有充足的时间退出。安理会的作用严格限于解决可以在链上裁决的健全性错误，并保护用户免受治理攻击。
144 |
145 | 详情看看：https://ethereum-magicians.org/t/proposed-milestones-for-rollups-taking-off-training-wheels/11571
146 |
147 | ### Arbitrum 的 Rullup 机制成熟度如何
148 | L2beat 评判 rullup 去中心化程度的 stage1 阶段，是按照 Stage 来区分的，目前 arb 和 Op 都是达到了 L2beat 评判 rullup 去中心化程度的 stage1 阶段，即
149 | Stage 0
150 | 该项目称其自己为rollup。
151 | 状态根被发布到以太坊L1。
152 | 状态转换函数的输入被发布到以太坊L1。
153 | 存在一个源可用节点，可以从以太坊L1数据重新创建状态。请注意，L2BEAT 团队尚未验证节点源代码的有效性。
154 |
155 | Stage 1
156 | 已部署完善、功能齐全的证明系统。
157 | 至少有 5 名外部参与者可以提交欺诈证明。
158 | 用户无需获得许可的操作员的帮助即可退出。
159 | 如果出现比安全理事会更集中的参与者进行不必要的升级，用户至少有 7 天的时间退出。
160 | 安全理事会已妥善设立。
161 |
162 | Stage 2
163 | 只有白名单参与者才能提交欺诈证明。
164 | 与链上可证明的错误无关的升级需要不到 30 天的时间才能退出。
165 | 安理会的行动并不局限于链上可证明的漏洞。
166 |
167 | 但是目前 Arb 只达到了 Stage 1 阶段
168 |
169 |
170 |
171 |
172 |
173 | ### 2024.12.13
174 | ### 如何解决争议
175 | 如何解决争议。假设 Alice 断言 Rollup 会的运行会产生某个结果，而 Bob 不同意，那协议该如何定夺，选择谁提交的结果呢？
176 | 这就用到一些争议解决的方式
177 |
178 | 争议解决方式：
179 | 交互式证明（Interactive Proving）：
180 | Alice 和 Bob 通过 L1 合约进行回合制交互，将争议范围逐步缩小。最后只需检查一个执行步骤的断言是否正确。目标是将计算负担尽量留在链下，减少对 L1 的依赖。
181 | 重执行交易（Transaction Re-execution）：L1 模拟一整笔交易的执行，看是否与断言一致。每笔交易需附带一个状态哈希值作为断言。
182 |
183 | 我理解交互式证明是对收集到的问题进行N/2，一直除下去，就能找到有争议的那笔交易，最后把有问题的去掉，其他上链即可，而重执行相当于对每笔交易都进行打标签，就有点问题
184 |
185 | 交互式证明的优势
186 | 链上效率：
187 |
188 | 乐观场景：交互式证明允许整个 Rollup 区块用一个状态断言表示结果，减少 L1 的存储开销。
189 | 悲观场景：即使有争议，L1 只需验证争议引导是否合规，避免完整重演交易。更高的 Gas Limit：
190 |
191 | 交互式证明脱离了以太坊单笔交易 Gas Limit 的限制，可以支持更大规模的交易。合约大小无限制：
192 |
193 | 交互式证明无需为每个 L2 合约在 L1 上部署对应合约，因此不受以太坊合约大小的限制。
194 | 重执行模式需要仿制合约，受限于以太坊合约大小。
195 |
196 | 实现弹性：
197 | 交互式证明对 EVM 无硬性依赖，可以支持额外的计算指令。
198 | 重执行模式严格受限于 EVM 的现有功能。
199 |
200 |
201 |
--------------------------------------------------------------------------------
/Muyec.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # Muyec
55 |
56 | 1. 自我介绍
57 |
58 | web3新新人。
59 |
60 | 2. 你认为你会完成本次残酷学习吗？
61 |
62 | 能
63 |
64 | ## Notes
65 |
66 |
67 |
68 | ### 2024.12.10
69 |
70 | 1.Arbitrum是什么：Arbitrum 是一个旨在扩展以太坊的技术套件，其核心产品 Arbitrum Rollup 是一种继承以太坊安全性的 Optimistic Rollup 协议，通过降低交易费用和提高交易速度解决了以太坊每秒交易量有限的问题。
71 |
72 | 2.Arbitrum的技术特点：Arbitrum Rollup 通过将用户交易数据压缩后批量提交至以太坊，并采用“乐观假设”机制，仅在争议情况下触发 L1 验证，从而显著减轻以太坊主网的负担，同时继承以太坊的安全性。
73 |
74 | 3.多链支持与灵活选择：Arbitrum 支持多条链并行运行，在以太坊主网上，有 2 条 Arbitrum 链：一条 Arbitrum Rollup 链，称为[“Arbitrum One”，](https://portal.arbitrum.one/)一条 AnyTrust 链[，称为“Nova](https://nova.arbitrum.io/)”;用户和开发人员可以选择适合他们的安全/交易成本需求的任何选项。
75 |
76 |
77 | ### 2024.12.11
78 |
79 | 欺诈证明:欺诈证明是一种逐步细分争议的机制，旨在通过不断缩小争议范围来验证区块和机器状态的正确性。在质询过程中，首先会将全局状态和区块哈希分为两部分，然后逐渐集中到单个区块。在执行阶段，质询被分解为更小的步骤，响应方需要提供数据证明每个步骤的执行状态与预期一致。每一轮质询中，响应方选择相邻的段进行挑战，逐步反驳对方的断言，并细分争议范围。质询的“度数”决定了每次分段的数量，确保挑战不断向前推进。与传统的等分协议不同，本协议采用非对称方式，由挑战者选择要质询的段，响应方提供校样数据。当质询无法得到有效解决时，响应方的状态哈希会被置为 0，从而导致超时失败，最终通过合同升级诊断和修复错误。这种机制不仅确保了挑战过程的透明性，也为错误修复提供了时间窗口。
80 |
81 |
82 | ### 2024.12.12
83 |
84 | Nitro 与 Classic:Arbitrum Nitro 是对 Arbitrum Classic 技术栈的升级，代表了 Arbitrum 技术发展的最新一步。两者的目标相似，都是创建一个接近以太坊的执行环境，用以太坊的欺诈证明保证 L2 状态的安全性。但 Nitro 相比 Classic 有显著的改进。在 Classic 中，Arbitrum 使用定制的虚拟机（AVM）执行代码，而在 Nitro 中，采用了 WebAssembly（Wasm），并将 Go 代码编译为 Wasm，这使得 Arbitrum 的 L2 状态机（ArbOS）能够直接包含以太坊的 Geth 实现，从而提高了兼容性。Nitro 的架构选择带来了多方面的优势：更低的费用、更好的以太坊兼容性和系统简化。
85 |
86 |
87 | ### 2024.12.13
88 |
89 | Arbitrum Orbit 是一个开发框架，允许用户基于 Arbitrum Rollup 的 L2 创建和启动 L3 网络。Orbit 支持用户定制链功能，包括隐私、权限、费用代币和治理等，同时提供专用吞吐量、流量隔离以及可靠的 Gas 价格，适合特定领域的快速机制设计与迭代，帮助实现更多的价值捕获。
90 | XAI 是基于 Arbitrum Orbit 的首个 L3，定位为专注游戏场景的链，相较于 Nova 通用链，XAI 能够提供更高的性能。它具备专属的计算和存储资源，适合计算密集型场景（如 AI 模型）。同时，XAI 原生集成了 Arbitrum 技术栈，包括 Nitro、BOLD 和 Stylus。
91 | Nitro 是 Arbitrum 的核心技术栈之一，通过直接编译 Geth 核心，显著提升了以太坊的兼容性和性能。这一升级使得 Orbit 链能够以更高效的方式运行，进一步优化用户体验。
92 |
93 |
94 | ### 2024.12.14
95 |
96 | 交互型 Rollup 确保断言（assertion）正确性的方式分为单轮和多轮交互两种。单轮交互型 Rollup（如 Optimism）中，断言包含调用结果，挑战者可在挑战窗口期内指出具体错误，链上合约模拟执行验证后，如果确有错误，则取消断言并罚没断言者保证金；若无挑战，断言最终确定。多轮交互型 Rollup（如 Arbitrum）通过挑战者与断言者的多轮交互缩小争议范围，最终由链上仲裁合约判定结果并惩罚错误方，设计目的是将链上仲裁的计算量降至最低。
97 |
98 |
99 | ### 2024.12.15
100 |
101 | 交互式证明:Arbitrum 通过交互式证明机制高效解决争议。以链下处理为主，仅在争议缩小到单步操作时，让 L1 合约参与验证，从而显著降低链上的计算和存储负担。这种机制基于双方的回合制交互，将争议逐步缩小至最小范围，最终解决问题。与重执行交易模式相比，交互式证明更加高效。乐观情况下，它允许一个 Rollup 区块仅包含一个断言，覆盖整条链的状态变化，从而节省 L1 空间开销；在悲观情况下，L1 合约也只需验证操作方向正确，而非重执行整笔交易。此外，交互式证明不受以太坊交易 Gas Limit 和合约大小的限制，这为 Arbitrum 提供了更高的交易吞吐量和合约灵活性。交互式证明是 Arbitrum 设计的核心驱动力，决定了其高效性和灵活性。大多数特性都围绕这一机制展开，显著提升了 Rollup 的性能和实用性，突破了传统 Rollup 设计的限制。
102 |
103 |
104 | ### 2024.12.16
105 |
106 | Arbitrum One 是基于 Optimistic Rollup 技术的以太坊扩展链，结合 L1 和 L2 架构，通过 EthBridge 和 Arbitrum 虚拟机（AVM）实现智能合约执行和数据交互。Nitro 是 Arbitrum One 的升级版本，提供更低费用、更高以太坊兼容性，并通过 zk 证明和优化的 Geth 引擎提升性能。Arbitrum Nova 则是专为游戏和社交应用等高频交互的 DApp 设计的链，采用 AnyTrust 技术，提供两种数据发布方式，通过牺牲部分安全性提升性能，适合成本敏感的用例。
107 |
108 |
109 | ### 2024.12.17
110 | Nitro 代表了 Arbitrum 技术发展的重要一步，是 Arbitrum One 主网的技术堆栈的升级版，我们现在称之为“Arbitrum Classic”，它比 2018 年最初的 Arbitrum 白皮书描述的技术更为先进。本文将解释 Nitro 升级的原因，并概述其相对于经典系统的核心优势。
111 | 从宏观来看，Classic 和 Nitro 系统的目标相似：都旨在提供一个尽可能接近 EVM（以太坊虚拟机）的执行环境，作为以太坊的第二层（L2）解决方案。即，通过以太坊自身的简洁欺诈证明来确保和执行 L2 虚拟机状态更新的安全性。
112 | 在 Arbitrum Classic 中，我们通过定制的虚拟机（AVM）实现这一目标，而 Arbitrum 的 L2 状态机实现（称为“ArbOS”）则是一个编译后上传到 AVM 的程序，具备模拟 EVM 执行能力的功能。
113 | 在 Nitro 中，我们采用 WebAssembly (Wasm) 替代 AVM 执行低级指令。由于 Go 代码可以编译为 Wasm，因此我们能够使用 Go 实现 ArbOS，并将 Geth（最广泛使用的以太坊实现）作为子模块嵌入其中。这一架构（直接使用 Geth 的 EVM 实现）是 Nitro 的核心特征，也是 Nitro 升级的关键。
114 |
115 |
116 | ### 2024.12.18
117 | $ARB 代币:$ARB 代币是一种 ERC-20 治理代币，持有者可以通过它参与 Arbitrum DAO 的链上治理，决定 Arbitrum One 和 Arbitrum Nova 链的运行和升级。代币的投票权根据持有数量加权，更多代币意味着更大的投票影响力。$ARB 代币可以委托给他人使用，方便没有时间审查提案的成员参与治理。$ARB 的初始供应量为 100 亿枚，每年最多铸造 2% 的新币，铸币活动由 DAO 通过提案管理。通过 $ARB 代币，持有者可以民主地影响 Arbitrum 生态系统的未来。
118 |
119 |
120 | ### 2024.12.19
121 | 治理框架:ArbitrumDAO的修订宪法设定了治理规则和程序，其中部分规则通过链上智能合约执行，其他则通过链下行动。所有规则具有同等约束力，且包括推荐指南，虽然不具约束力，但作为良好治理的建议。该宪法描述了ArbitrumDAO和Arbitrum基金会的治理框架，并明确了可修改的程序。
122 |
123 | 链所有权:ArbitrumDAO可授权创建额外的Layer-2链，这些链使用Arbitrum技术结算到以太坊。每个新增的链必须通过AIP授权，且根据是否受到$ARB代币管理，分为治理链和非治理链。治理链受到$ARB代币管理，而非治理链则不受代币管理，但都需在以太坊上结算。
124 |
125 | DAO提案和投票程序:AIP提案的提交和投票遵循严格的程序。首先，提案会进行体温检查（1周讨论），然后进行正式AIP提交并进行为期3天的投票。投票期后，DAO成员将在14-16天内投票决定提案是否通过。每个提案需标明是否为宪法AIP，宪法AIP修改章程，而非宪法AIP包括资金申请和信息性提案。
126 |
127 | 提案通过标准:AIP提案的通过需要满足特定的投票条件：宪法AIP要求至少5%的$ARB代币参与投票，非宪法AIP要求至少3%。投票期间，如果达成条件，提案会进入下一阶段。若未通过，则结束流程。通过后，宪法AIP将进入后续阶段执行，非宪法AIP则直接执行。
128 |
129 | 提案实施阶段:提案通过后的实施分为多个阶段：L2等待期、L1消息和L1等待期。经过这些阶段后，AIP将最终实施。实施可以通过L1上的确认消息来启动，也可以通过治理链间的交易来完成。整个AIP提案和执行流程一般需要27到37天，具体时长取决于提案的类型。
130 |
131 |
132 | ### 2024.12.20
133 | Arbitrum 空投积分系统依据用户在 Arbitrum One 和 Arbitrum Nova 的活动来确定代币分配，积分上限为 15 分。快照日期之前，每完成一项符合条件的操作可获得 1 分；在 Arbitrum Nitro 上线（2022 年 8 月 31 日）之前完成的得分（至少 3 分）可翻倍。符合条件的操作包括桥接资金、完成多次交易、与多个智能合约交互以及交易总额达到指定金额等；Nova 上的积分最多为 4 分，若 One 上得分已达 4 分，还可额外加 1 分。此外，DAO 空投面向 Arbitrum 生态中的协议及以太坊贡献者集体，分配依据协议的活跃度、TVL、用户交互等多项定性与定量指标。空投代币自 2023 年 3 月 23 日起开放领取；投资者和团队代币则按 4 年锁定规则分期释放，首次解锁在代币生成事件一年后（2024 年 3 月 16 日），此后剩余部分按月线性解锁。
134 |
135 |
136 | ### 2024.12.21
137 | Arbitrum 的技术优势与市场地位：
138 | Arbitrum 是以太坊第二层扩容方案的领先者，采用 Optimistic Rollup 技术，兼具扩展性和隐私特性。它支持未修改的 EVM 合约和以太坊交易，同时继承以太坊的安全性。截至 2022 年 6 月，Arbitrum 的锁定价值占第二层市场的 50.88%，在竞争中占据主导地位，相比 Polygon 和 Optimism 等方案表现更为优越。
139 | ARB 代币的市场表现与未来展望：
140 | ARB 代币于 2023 年 3 月 23 日上市，初期价格波动在 0.60 美元至 0.66 美元之间（取决于供应条件）。根据预测，2023 年价格或达到 1.35 美元至 2.32 美元之间，2024 年进一步上涨至 5.41 美元至 7.04 美元。Arbitrum 生态系统的扩大、机构投资者的关注及交易所的支持，预计将成为推动 ARB 代币价值增长的主要驱动因素。
141 |
142 |
143 | ### 2024.12.22
144 | Arbitrum的地位：
145 | Arbitrum 作为当前最领先的二层扩容解决方案之一，在各大扩容协议中占据了显著的市场份额。据 L2BEAT 数据显示，Arbitrum 在所有二层网络中以超 36 亿美元的市值领先，约占二层总锁仓量的 57%。而根据 DefiLlama 的统计数据，Arbitrum 的总锁仓量为 25.5 亿美元，略低于 L2BEAT 的数据。尽管如此，Arbitrum 生态系统依然显示出强大的吸引力，其中锁仓量超过 1 亿美元的项目包括知名的 DeFi 协议如 SushiSwap、GMX、Stargate、Curve、Dopex、Treasure DAO、Synapse 和 dForce 等，这些项目的表现显著推动了平台的成长。在 Arbitrum 上，SushiSwap 是占据主导地位的项目，单项目锁仓量超过 5 亿美元，占总锁仓量的 20%以上，紧随其后的是 GMX，锁仓量达到 4.38 亿美元。此外，在 DefiLlama 统计的 Arbitrum 生态中的 72 个项目中，40 个项目的锁仓量都超过了 100 万美元，且大多数是支持多链的协议，进一步提升了 Arbitrum 网络的去中心化金融生态影响力。从用户参与度来看，Arbitrum 的存款地址数在其主网上线后的去年激增，而最近几个月保持缓慢上升的趋势，目前累计存款地址已接近 25 万个。这些数据显示，Arbitrum 无论是在锁仓量还是生态增长方面，都在不断巩固其在二层扩容领域的领导地位。
146 |
147 |
148 | ### 2024.12.23
149 | 出入金与钱包支持：
150 | 多个主流中心化交易所已集成 Arbitrum One 主网，支持 ETH 和 USDT 的充提，包括 Bitget、币安、Bybit、Crypto.com、FTX、火币、KuCoin、MEXC、OKX 等交易所。钱包方面，已有 24 个钱包支持 Arbitrum One 主网，如 BitKeep、Coinbase Wallet、MetaMask、DeBank、imToken、MathWallet、Trust Wallet、Zapper、Zerion 等。此外，Banxa 提供 Visa 或 Mastercard 卡直接购买 ETH 和 USDT 的服务；CryptoRefills 支持用户通过比特币等加密货币购买礼品卡或代金券，同时支持包括 Arbitrum 在内的多个网络；Mt Pelerin 和 Transak 等法币网关也支持在 Arbitrum 上购买和出售加密货币。
151 |
152 | 跨链桥与资产转移：
153 | Arbitrum One Bridge 是官方跨链桥，允许在 L1 和 L2 之间进行多种代币的跨链转移，L1 到 L2 约需 10 分钟，L2 到 L1 约需 8 天。Across Protocol 支持以太坊、Optimism、Arbitrum 和 Boba 的跨链，但目前不支持 L2 间直接转移。Multichain 和 Celer cBridge 是较为热门的跨链工具，分别支持包括 Arbitrum 在内的多个网络；Hop Protocol 专注于以太坊、Polygon、Optimism 和 Arbitrum 等生态内的跨链转移。其他工具如 BoringDAO、Bungee、Connext、deBridge、LI.FI 和 RenBridge 等均支持多个网络的资产跨链转移或兑换，部分项目还发布了原生代币或激励计划。此外，基于 LayerZero 的 Stargate 和 Synapse Protocol 提供高效的跨链解决方案，支持以太坊、Arbitrum、BNB Chain 等主流网络间的互操作。Composable Finance Mosaic、SOCKET、Rubic 等工具也整合了多种桥接方案，为用户提供了更多选择。
154 |
155 |
156 | ### 2024.12.24
157 |
158 | Tracer DAO：衍生品元协议与治理发展
159 | Tracer DAO 是一个基于 Balancer 构建的衍生品元协议，其核心应用是 Perpetual Pools，用户可通过杠杆代币形式实现无需清算且长期持有的交易，还能通过质押赚取奖励，同时具有高资本效率和可组合性。Tracer V1 收取 1% 的协议费用，V2 即将推出，将允许无需许可的部署。项目已发布治理代币 TCR，并将 10% 分配用于流动性挖矿奖励计划。此外，Tracer DAO 曾获 Framework Ventures 等知名机构投资，共融资 900 万美元。
160 |
161 | ### 2024.12.25
162 |
163 | Arbitrum 生态：多元化的应用布局
164 | 在 Arbitrum 生态上，主要项目覆盖兑换、借贷、流动性管理和 NFT 市场等领域。例如，Swapr、ZipSwap 等支持多链 AMM；Aave V3、Vesta Finance 等提供跨链资产流动性和借贷服务；iZUMi Finance、YIN Finance 等专注流动性挖矿和主动流动性管理；Superfluid 则实现可编程资金流；NFT 市场方面，Stratos 和 TreasureDAO 热度较高，后者通过 MAGIC 代币计价并推出 Bridgeworld 元宇宙游戏，增强了其生态吸引力。
165 |
166 | ### 2024.12.26
167 | 比特币现货ETF获批及以太坊生态的快速发展:1月11日，比特币现货ETF终于获得批准，为传统投资者提供了新的进入加密市场的途径。与此同时，以太坊即将迎来Dencun升级，其中以EIP-4844为核心的技术将大幅降低L2交易费用并提升性能，这使得以太坊在扩展性方面获得了更强的支持，Arbitrum作为以太坊的主要L2解决方案，也因此成为市场关注的焦点。
168 |
169 | Arbitrum生态的崛起：Arbitrum生态在不断扩展，Offchain Labs推出的Arbitrum Orbit使得开发者能够无需许可地构建专用链。这一创新使得基于以太坊的多链架构成为可能，且每个Orbit链都具备高度自定义能力，支持定制Gas费用、吞吐量、隐私和治理等功能。特别是Arbitrum Orbit对自定义Gas代币的支持，能够进一步增强链内代币的实用性并推动生态系统的发展。
170 |
171 | Arbitrum Orbit生态项目的潜力:目前，已有多个项目计划通过Arbitrum Orbit推出专用链，涵盖游戏、NFT、DeFi等多个领域。例如，Xai专注于为游戏打造去中心化平台，Frame面向创作者和收藏家，而RARI Chain则通过低交易成本和集成多个平台为NFT市场提供支持。这些创新项目展示了Arbitrum Orbit在多元化应用中的巨大潜力，也为以太坊生态的未来增添了新的动力。
172 |
173 |
174 | ### 2024.12.27
175 | Arbitrum Orbit 的技术优势与近期更新:
176 | Arbitrum Orbit 支持 Rollup 和 AnyTrust 两种模式，提供高吞吐量、自定义 Gas 代币、治理、隐私及协议逻辑配置等灵活特性。其最新更新允许 Orbit 链使用特定 ERC-20 代币作为 Gas，从而增强了链的可定制性。此外，Orbit 借助 Stylus 实现 EVM+ 兼容性，支持使用 Solidity、C、C++ 和 Rust 编写智能合约，为开发者提供高性能和跨语言合约的能力。Orbit 生态现已吸引 18 个项目入驻，涵盖游戏、NFT、衍生品和流动性等领域。与 Caldera、AltLayer、Conduit 的合作，则进一步降低了开发者启动自定义 Rollup 的门槛。
177 |
178 | ### 2024.12.28
179 |
180 | Orbit 生态项目亮点及其影响:
181 | Orbit 生态中涌现了多个具有代表性的项目，为去中心化生态的发展注入了活力。例如，专注去中心化游戏生态的 Xai，已上线主网并计划推出链上卡牌游戏《Final Form》，目标是提供抽象的钱包与账户体验；主打低成本交易和无 Gas 铸造的 RARI Chain，支持信用卡支付并集成 LayerZero 等合作伙伴；借助 AltLayer 和 Orbit 部署 Layer3 Rollup 的 Cometh，专注服务卡牌游戏 Cosmik Battle；以及 Superposition，通过去中心化订单簿提供共享深度流动性。这些项目的多样化场景展示了 Orbit 在推动创新和应用落地方面的潜力，同时也证明 Orbit 平台已经成为开发者构建高性能去中心化应用的核心支柱，为 Arbitrum 生态向多功能区块链平台扩展奠定了坚实基础。
182 |
183 |
184 | ### 2024.12.29
185 | Arbitrum 技术栈深度解析：
186 | Stylus 技术框架
187 | Stylus 是 Arbitrum 的新一代智能合约开发框架，支持多种编程语言的智能合约开发，包括 Rust、C++、C 以及其他可编译为 WASM 的语言。Stylus 与以太坊虚拟机（EVM）完全兼容，提供高性能的执行环境，并支持跨语言互操作，确保与以太坊生态系统的良好兼容性。
188 |
189 | BOLD (Block Operation Ledger Derivation) 技术
190 | BOLD 技术旨在优化区块操作和账本派生，提升链上数据处理效率，并增强跨链通信能力。其主要优势在于降低链上存储成本、提高交易处理速度，并优化数据可用性证明，从而进一步提升区块链的整体性能和效率。
191 |
192 | Nitro 引擎架构
193 | Nitro 引擎架构包含多个关键系统组件，如交易管理器、状态管理器、共识引擎和网络层。其设计旨在提供高吞吐量、低延迟、强一致性和可扩展性，确保 Arbitrum 在处理交易和智能合约时能够保持高效与稳定。
194 |
195 |
196 | ### 2024.12.29
197 | Arbitrum 短期激励计划:
198 | Arbitrum 在分发 ARB 代币后开始去中心化，Arbitrum DAO 负责治理 Arbitrum One 和 Arbitrum Nova，代币持有者可通过投票参与决策。DAO 财库保留了 42.78% 的 ARB 代币，用于激励生态建设。为了推动生态发展，社区多次呼吁启动激励计划。
199 |
200 | 激励计划启动与提案通过:
201 | 2023 年 8 月 15 日，Arbitrum 激励计划工作组首次会议由 Camelot、Gauntlet、GMX 等团队组成，并于 9 月 18 日在 Snapshot 上通过了短期激励计划（STIP）的提案。最终，Arbitrum DAO 在 Tally 上通过了该提案，决定分配 5000 万 ARB 代币（约合 4100 万美元），用于激励项目，资金将于 2024 年 1 月 31 日前分配。
202 |
203 | 资金分配与投票机制:
204 | 此次激励计划的资金分配通过两轮投票程序完成：首先是 Snapshot 上的民意投票，接着在 Tally 上进行链上投票。提案获得 99% 的支持后，5000 万 ARB 代币被分配至一个多签钱包，由 DAO 代表管理，进行项目赠款分配。
205 |
206 | 赠款申请与条件:
207 | 短期激励计划的资金分配依据项目在 Arbitrum 上的表现，主要考虑项目的运行时间、TVL（总价值锁仓）和过去 30 天的交易量。申请的项目必须满足明确的支出计划，承诺提供相关运营数据，并完成 Arbitrum 基金会的 KYC 认证。资金只能用于 Arbitrum 网络上的激励，不能转化为其他资产。
208 |
209 | 项目支持与生态参与:
210 | 此次激励计划显示，原生项目如 GMX 等因其高 TVL 和交易量获得更多支持。此外，项目方不仅要确保项目本身的质量，还需积极参与生态活动，如成为多签钱包的代表、治理代表等，这些都能提升项目在 Arbitrum 网络中的影响力，进而增加获得资助的机会。
211 |
212 |
--------------------------------------------------------------------------------
/NSXX2021.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | ---
6 |
7 | # NSXX2021
8 |
9 | 1. NSXX 对 Arbitrum 有兴趣
10 | 2. 应该可以完成本次残酷学习
11 |
12 | ## Notes
13 |
14 |
15 |
16 | ### 2024.12.10
17 |
18 | 笔记内容
19 |
20 | ### 2024.12.10
21 |
22 |
23 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Arbitrum 残酷共学
2 |
3 | ## 介绍
4 |
5 | Arbitrum 是一个以太坊扩展解决方案，通过优化以太坊网络的性能和降低交易费用，为用户和开发者提供了更高效的区块链体验。
6 |
7 | 在充满无限可能的 Web3 新世界里，Arbitrum 已经成为 Layer 2 中不可忽视的存在。为此，LXDAO 发起了「Arbitrum 残酷共学」，想召集一群人共同创造一个积极向上的 Arbitrum 学习和交流环境。
8 |
9 | ## 关键词
10 |
11 | Arbitrum,Non-technical background,beginner-friendly
12 |
13 | ## 面向人群
14 |
15 | 背景不限，重点在于你是否对 Arbitrum 技术感兴趣。
16 |
17 | ## 报名时间
18 |
19 | - 开始时间：2024-12-03
20 | - 结束时间：2024-12-09
21 |
22 | ## 共学时间
23 |
24 | - 开始时间：2024-12-10
25 | - 结束时间：2024-12-30
26 |
27 | ## 发起人
28 |
29 | - 姓名：LXDAO Forge
30 | - GitHub ID: yuxing11
31 | - Telegram：@yuxingci
32 | - Email：217423yxy@gmail.com
33 |
34 | ## 发起组织
35 |
36 | - [LXDAO](https://lxdao.io/) 
37 |
38 | ## 请假规则
39 |
40 | 每周请假 1 次
41 |
42 | ## 社群
43 |
44 | Telegram：https://t.me/LXDAO/15575
45 |
46 | ## 共学内容
47 |
48 | #### 1. Arbitrum 基础介绍
49 |
50 | - [使命、特点及原理](https://docs.arbitrum.io/welcome/arbitrum-gentle-introduction)
51 |
52 | #### 2. Arbitrum 技术架构
53 |
54 | **初级知识点：**
55 |
56 | - Layer 2 技术类型
57 | - [什么是 Rollup、ZK Rollups 与 Optimistic，Arbitrum 的区别](https://cloud.tencent.com/developer/news/1003179)
58 | - 工作原理
59 | - [官方文档：欺诈证明](https://docs.arbitrum.io/how-arbitrum-works/fraud-proofs/challenge-manager)
60 | - [非官方介绍：交互式欺诈证明](https://www.theblockbeats.info/news/26507)
61 | - Arbitrum 名词解析
62 | - [官方文档：One、Nitro、Nova](https://docs.arbitrum.io/how-arbitrum-works/why-nitro)
63 | - [非官方介绍：One、Nitro、Nova 详解](https://community.dorahacks.io/t/arbitrum-one-nitro-nova/562)
64 |
65 | **进阶知识点：**
66 |
67 | - [官方文档：Inside Arbitrum Nitro](https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro)
68 | - [深入理解 Arbitrum](https://www.theblockbeats.info/news/26507)
69 | - [Arbitrum 创新的技术路线图](https://medium.com/offchainlabs/your-chain-your-rules-offchain-labs-technical-roadmap-to-fuel-arbitrum-innovation-f787f2e85966)
70 |
71 | #### 3. 生态系统
72 |
73 | - [Messari：深度分析 Arbitrum 的繁荣生态](https://www.theblockbeats.info/news/35982)
74 | - [全览 Arbitrum 上百个生态项目](http://www.yuanli24.com/news/11836)
75 | - [Arbitrum Orbit 生态探索](https://www.techflowpost.com/article/detail_15657.html)
76 |
77 | #### 4. 代币经济模型
78 |
79 | - [$ARB 代币概述](https://docs.arbitrum.foundation/concepts/arb-token)
80 | - [空投资格和分配规范](https://docs.arbitrum.foundation/airdrop-eligibility-distribution)
81 | - [代币流通供应量](https://docs.arbitrum.foundation/token-supply)
82 | - [ARB 经济模型详解](https://foresightnews.pro/article/detail/28817)
83 | - [代币经济、机构成本、估值分析](https://foresightnews.pro/article/detail/28668)
84 |
85 | #### 5. Arbitrum DAO 治理
86 |
87 | - [DAO 宪法](https://docs.arbitrum.foundation/dao-constitution)
88 | - [DAO 术语表](https://docs.arbitrum.foundation/dao-glossary)
89 | - [如何提交提案](https://docs.arbitrum.foundation/how-tos/create-submit-dao-proposal)
90 | - [治理理念](https://docs.arbitrum.foundation/concepts/arbitrum-dao)
91 | - [治理架构](https://docs.arbitrum.foundation/security-council-members)
92 | - [官方治理文档](https://docs.arbitrum.foundation/gentle-intro-dao-governance)
93 | - [治理论坛](https://forum.arbitrum.foundation/)
94 | - [DAO 治理案例分析](https://foresightnews.pro/article/detail/45035)
95 |
96 | ### 共学进度
97 |
98 | 21 天学习进度安排如下：
99 |
100 | **第一周（1-7 天）：基础概念与技术入门**
101 |
102 | 本周重点学习 Arbitrum 的基本介绍和技术架构的初级知识点：
103 |
104 | - • 第 1-2 天：了解 Arbitrum 的使命、特点及基本原理
105 | - • 第 3-5 天：认识 Rollup 概念并深入理解欺诈证明机制
106 |
107 | **第二周（8-14 天）：技术深化与生态探索**
108 |
109 | 本周重点学习技术进阶知识和生态系统：
110 |
111 | - • 第 8-10 天：学习 Arbitrum 三次升级（One、Nitro、Nova）的细节
112 | - • 第 11-12 天：了解技术路线图和创新特点
113 | - • 第 13-14 天：探索 Arbitrum 生态系统和应用案例
114 |
115 | **第三周（15-21 天）：代币经济与治理机制**
116 |
117 | 本周重点学习代币经济模型和 DAO 治理：
118 |
119 | - • 第 15-17 天：深入理解$ARB 代币经济模型
120 | - • 第 18-19 天：学习 DAO 治理架构和基本概念
121 | - • 第 20-21 天：了解提案流程和实际治理案例
122 |
123 | ## 更多信息
124 |
125 | ### **共学形式**
126 |
127 | - **自主学习**：每天围绕选定的 Arbitrum 学习资料进行学习，建议每天投入一小时进行资料阅读、思考、提问、交流及打卡。
128 | - **共学 Badge 认证：** 完成 Arbitrum 残酷共学 21 天共学打卡并通过学习证明审核即可获取 。
129 | - **线上讨论：** 随时可以在电报频道发起讨论，共学笔记分享交流。
130 | - **每周答疑**：每周由共学助教组织一次共学讨论会，对大家提到频率高的共学问题做出解答。
131 | - **共同目标：**「Arbitrum 残酷共学」将可持续地从第 1 期有序的推进到 N 期，21 天为一个周期，从基础开始，初步掌握关于 Arbitrum 的基础知识， Arbitrum 的生态现状， Arbitrum DAO 的治理规则，进而最终实现对 Arbitrum 较为全面完整的了解。
132 |
133 | ## 报名和打卡规则
134 |
135 | 因为残酷共学的报名和打卡是基于 GitHub 进行开展的，如果你是非开发者或者对 git 操作不熟悉，请先阅读此文档：[残酷共学 GitHub 新手教程](https://www.notion.so/lxdao/GitHub-53fca5ba49bb40c69e4e40e69f58f416)
136 |
137 | - 报名:
138 |
139 | - Step01：Fork 本仓库。
140 | - Step02：复制 Template.md 创建你的个人笔记文件，并根据文档指引填写你的信息，并将文件重命名为你的名字：YourName.md。
141 | - Step03：创建一个 PR 到当前仓库，本残酷共学助教会对你的 PR 进行 review，review 通过后，你的 PR 会被 merge 到 main 分支，这个时候你会收到邀请加入这个仓库 contribution 的邮件，接受邀请后，你会自动获得 main 分支的 push 权限。
142 | - Step04：完成以上三个步骤，恭喜你报名成功，后续就可以将你的学习记录直接 push 到 main 分支进行更新。
143 | - 请加入 Arbitrum 残酷共学群组保持交流：(https://t.me/LXDAO/15575)。加入群组后请在群里报到一下方便助教记录。
144 |
145 | - 打卡：
146 | - 报名成功后，你将拥有 main 分支的 push 权限，你需要将每天学习笔记按日期更新到你的 YourName.md 文档中，提交更新后，我们会自动更新你的打卡状态到下面的打卡记录表。
147 | - 如果你不在 UTC+8 时区，需要添加时区 code 到你的 YourName.md 文件的开始，错误的时区设置可能会使自动化打卡脚本错误计算打卡时间，具体请参考：https://github.com/IntensiveCoLearning/template/blob/main/Template.md?plain=1#L1
148 | - 当你提交笔记时，请确保以下几点，否则打卡可能会失败：
149 | - 在 YourName.md 文档，请将笔记内容放到以下代码块中，且 `` 和 `` 不能删除:
150 | ```
151 |
152 | ### 日期
153 | 笔记内容
154 |
155 | ```
156 | - 日期格式为 `### 2024.12.10`，请不要随意更改
157 |
158 | ## 残酷共学打卡记录表
159 |
160 | ✅ = Done ⭕️ = Missed ❌ = Failed
161 |
162 |
163 | | Name | 12.10 | 12.11 | 12.12 | 12.13 | 12.14 | 12.15 | 12.16 | 12.17 | 12.18 | 12.19 | 12.20 | 12.21 | 12.22 | 12.23 | 12.24 | 12.25 | 12.26 | 12.27 | 12.28 | 12.29 | 12.30 |
164 | | ------------- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
165 | | [Yi-fantasy](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/Yi-fantasy.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
166 | | [onthebigtree](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/onthebigtree.md) | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | |
167 | | [Soleil-YSY](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/Soleil-YSY.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
168 | | [jiejie](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/jiejie.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
169 | | [StarryDesert](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/StarryDesert.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ |
170 | | [a-super-cat](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/a-super-cat.md) | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | |
171 | | [pillowtalk-Qy](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/pillowtalk-Qy.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
172 | | [hechichu](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/hechichu.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | |
173 | | [nocb](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/nocb.md) | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ |
174 | | [ChinesePaladin61](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/ChinesePaladin61.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
175 | | [jjeejj](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/jjeejj.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
176 | | [happylucie](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/happylucie.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
177 | | [Rey666666](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/Rey666666.md) | ✅ | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | |
178 | | [CHENFANGC](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/CHENFANGC.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ |
179 | | [Muyec](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/Muyec.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ |
180 | | [YuanboXie](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/YuanboXie.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
181 | | [JacksonStack](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/JacksonStack.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
182 | | [Helen2022a](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/Helen2022a.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
183 | | [stualan](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/stualan.md) | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ |
184 | | [fuhaooo](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/fuhaooo.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ⭕️ | ❌ | | |
185 | | [pliker-git](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/pliker-git.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ❌ | | | | | |
186 | | [noyyyy](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/noyyyy.md) | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | |
187 | | [NSXX2021](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/NSXX2021.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
188 | | [317232](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/317232.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | |
189 | | [Marcus](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/Marcus.md) | ⭕️ | ✅ | ✅ | ✅ | ⭕️ | ❌ | | | | | | | | | | | | | | | |
190 | | [yuhui](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/yuhui.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
191 | | [HenryWei](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/HenryWei.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
192 | | [missingtheway](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/missingtheway.md) | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ⭕️ | ❌ | | | | | | | | |
193 | | [iavl](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/iavl.md) | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | |
194 | | [HeliosLz](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/HeliosLz.md) | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ |
195 | | [linyuanye3](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/linyuanye3.md) | ✅ | ⭕️ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ✅ | ⭕️ | ✅ | ⭕️ | ❌ | | | |
196 | | [joyc](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/joyc.md) | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | |
197 | | [CornellZheng](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/CornellZheng.md) | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | |
198 | | [YOUKUAIHAOMUTOU](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/YOUKUAIHAOMUTOU.md) | ✅ | ✅ | ⭕️ | ⭕️ | ✅ | ❌ | | | | | | | | | | | | | | | |
199 | | [wodeche](https://github.com/IntensiveCoLearning/Arbitrum/blob/main/wodeche.md) | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | |
200 |
201 |
202 |
203 |
204 |
205 |
206 |
207 |
208 |
209 |
210 |
211 |
212 |
213 |
214 |
215 |
216 |
217 |
218 |
219 |
220 |
221 |
222 |
223 |
224 |
225 |
226 |
227 |
228 |
229 |
230 |
231 |
232 |
233 |
234 |
235 |
236 |
237 |
238 |
239 |
240 |
241 |
242 |
243 |
244 |
245 |
246 |
247 |
248 |
249 |
250 |
251 |
252 |
253 |
254 |
255 |
256 |
257 |
258 |
259 |
260 |
261 |
262 |
263 |
264 |
265 |
266 |
267 |
268 |
269 |
270 |
271 |
272 |
273 |
274 |
275 |
276 |
277 |
278 |
279 |
280 |
281 |
282 |
283 |
284 |
285 |
286 |
287 |
288 |
289 |
290 |
291 |
292 |
293 |
294 |
295 |
296 |
297 |
298 |
299 |
300 |
301 |
302 |
303 |
304 |
305 |
306 |
307 |
308 |
309 |
310 |
311 |
312 |
313 |
314 |
315 |
316 |
317 |
318 |
319 |
320 |
321 |
322 |
323 |
324 |
325 |
326 |
327 |
328 |
329 |
330 |
331 |
332 |
333 |
334 |
335 |
336 |
337 |
338 |
339 |
340 |
341 |
342 |
343 |
344 |
345 |
346 |
347 |
348 |
349 |
350 |
351 |
352 |
353 |
354 |
355 |
356 |
357 |
358 |
359 |
360 |
361 |
362 |
363 |
364 |
365 |
366 |
367 |
368 |
369 |
370 |
371 |
372 |
373 |
374 |
375 |
376 |
377 |
378 |
379 |
380 |
381 |
382 |
383 |
384 |
385 |
386 |
387 |
388 |
389 |
390 |
391 |
392 |
393 |
394 |
395 |
396 |
397 |
398 |
399 |
400 |
401 |
402 |
403 |
404 |
405 |
406 |
407 |
408 |
409 |
410 |
411 |
412 |
413 |
414 |
415 |
416 |
417 |
418 |
419 |
420 |
421 |
422 |
423 |
424 |
425 |
426 |
427 |
428 |
429 |
430 |
431 |
432 |
433 |
434 |
435 |
436 |
437 |
438 |
439 |
440 |
441 |
442 |
443 |
444 |
445 |
446 |
447 |
448 |
449 |
450 |
451 |
452 |
453 |
454 |
455 |
456 |
457 |
458 |
459 |
460 |
461 |
462 |
463 |
464 |
465 |
466 |
467 |
468 |
469 |
470 |
471 |
472 |
473 |
474 |
475 |
476 |
477 |
478 |
479 |
480 |
481 |
482 |
483 |
484 |
485 |
486 |
487 |
488 |
489 |
490 |
491 |
492 |
493 |
494 |
495 |
496 |
497 |
498 |
499 |
500 |
501 |
502 |
503 |
504 |
505 |
506 |
507 |
508 |
509 |
510 |
511 |
512 |
513 |
514 |
515 |
516 |
517 |
518 |
519 |
520 |
521 |
522 |
523 |
524 |
525 |
526 |
527 |
528 |
529 |
530 |
531 |
532 |
533 |
534 |
535 |
536 |
537 |
538 |
539 |
540 |
541 |
542 |
543 |
544 |
545 |
546 |
547 |
548 |
549 |
550 |
551 |
552 |
553 |
554 |
555 |
556 |
557 |
558 |
559 |
560 |
561 |
562 |
563 |
564 |
565 |
566 |
567 |
568 |
569 |
570 |
571 |
572 |
573 |
574 |
575 |
576 |
577 |
578 |
579 |
580 |
581 |
582 |
583 |
584 |
585 |
586 |
587 |
588 |
589 |
590 |
591 |
592 |
593 |
594 |
595 |
596 |
597 |
598 |
599 |
600 |
601 |
602 |
603 |
604 |
605 |
606 |
607 |
608 |
609 |
610 |
611 |
612 |
613 |
614 |
615 |
616 |
617 |
618 |
619 |
620 |
621 |
622 |
623 |
624 |
625 |
626 |
627 |
628 |
629 |
630 |
631 |
632 |
633 |
634 |
635 |
636 |
637 |
638 |
639 |
640 |
641 |
642 |
643 |
644 |
645 |
646 |
647 |
648 |
649 |
650 |
651 |
652 |
653 |
654 |
655 |
656 |
657 |
658 |
659 |
660 |
661 |
662 |
663 |
664 |
665 |
666 |
667 |
668 |
669 |
670 |
671 |
672 |
673 |
674 |
675 |
676 |
677 |
678 |
679 |
680 |
681 |
682 |
683 |
684 |
685 |
686 |
687 |
688 |
689 |
690 |
691 |
692 |
693 |
694 |
695 | ## 统计数据
696 |
697 | - 总参与人数: 35
698 | - 完成人数: 12
699 | - 完成用户: Yi
700 | - 全勤用户: Yi
701 | - 淘汰人数: 22
702 | - 淘汰率: 62.86%
703 | - Fork人数: 48
704 |
705 |
--------------------------------------------------------------------------------
/Rey666666.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # {你的名字}
55 |
56 | 1. 自我介绍 小白rey
57 | 2. 你认为你会完成本次残酷学习吗？yes
58 |
59 | ## Notes
60 |
61 |
62 |
63 | ### 2024.12.10
64 |
65 | 笔记内容
66 | Refer:https://docs.arbitrum.io/welcome/arbitrum-gentle-introduction
67 | 一.ARB的使命，特点及原理
68 | 1.使命
69 | 以太坊的设计中，TPS的吞吐量相对较低，原因主要涉及到安全性、去中心化和可扩展性三个核心的区块链设计原则。传统的以太坊主链无法满足大规模应用（如去中心化金融 DeFi、大量的 NFT 操作等）对交易吞吐量的需求。因此，Layer 2 解决方案被提出。
70 | 2.特点
71 | （1）.Arbitrum Rollup：Arbitrum在 Layer 2 上处理交易，但这些交易的状态更新会定期提交到以太坊主链。即假设交易是有效的，除非有人提出挑战。即使存在错误或欺诈行为，也可以通过挑战期解决问题，确保系统的最终正确性。与L1不同，我们不要求以太坊节点处理每笔 Arbitrum 交易；相反，以太坊对 Arbitrum 采取“在被证明有罪之前无罪”的态度。第 1 层最初“乐观地假设”Arbitrum 上的活动遵循正确的规则。如果发生违规行为（即有人声称“现在我拥有了你所有的钱”），则可以在 L1 上对此索赔提出异议；欺诈将被证明，无效索赔将被忽略，恶意方将受到经济处罚。
72 | （2）.高吞吐量和低延迟：Arbitrum 交易是分批提交到 L1 上的；通常，单个批次（在单个 L1 交易中提交）将包含数百个 L2 交易。分批处理摊销了与 L1 交互的间接成本，因此与一次发布单个交易相比，可以节省大量成本。此外，交易数据以压缩形式发布到 L1 上（并且仅在 L2 环境中解压缩），从而进一步最大限度地减少了交易对 L1 的占用空间。
73 | （3）.较低的交易费用：Arbitrum 可以将大量的交易打包成一个批次提交到主链，节省了计算资源，因此交易成本大幅下降。
74 | （4）.兼容以太坊：Arbitrum 具有很高的兼容性，可以运行与以太坊主链完全相同的智能合约，甚至开发者可以使用现有的 Solidity 代码。这样，现有的以太坊应用可以通过简单的迁移或连接到 Arbitrum，获得更高的吞吐量和更低的交易费用，而不需要重写代码或改变架构。
75 | （5）.保留了以太坊去中心化的特性及安全性：输入 Arbitrum Rollup 链的数据（即用户的交易数据）直接发布在以太坊上。因此，只要以太坊本身安全运行，任何感兴趣的人都可以看到 Arbitrum 中 发生的事情，并有能力检测和证明欺诈行为。
76 |
77 | ### 2024.12.10
78 |
79 | ### 2024.12.11
80 |
81 | 笔记内容
82 | 3.ARB的两条主链
83 | （1）.Arbitrum Rollup:a.此链又称“Arbitrum One”，输入 Arbitrum Rollup 链的数据（即用户的交易数据）直接发布在以太坊上。只要以太坊本身安全运行，任何感兴趣的人都可以看到 Arbitrum 中发生的事情，并有能力检测和证明欺诈行为。
84 | （2）.Arbitrum AnyTrust：a.此链又称“Nova”，不具备 Rollup 链那样的去中心化 / 无需信任 / 无需许可的安全保证，因此可以提供更低的费用。
85 | b.此链与Rollup链的区别：在 Rollup 中，所有数据都发布在 L1 上（允许任何人无需许可加入成为验证者），而在 AnyTrust 中，数据是在链下管理的。在出现挑战的情况下，AnyTrust 链会恢复为“rollup 模式”；这里的安全假设是至少有 2 名委员会成员是诚实的（即，他们会在必要时提供数据）。
86 |
87 | ### 2024.12.11
88 |
89 |
--------------------------------------------------------------------------------
/Soleil-YSY.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Pacific/Auckland
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # {你的名字}
55 |
56 | 1. 自我介绍
57 | 2. 你认为你会完成本次残酷学习吗？
58 |
59 | ## Notes
60 |
61 |
62 |
63 | ### 2024.07.11
64 |
65 | 笔记内容
66 |
67 | ### 2024.07.12
68 |
69 |
70 |
--------------------------------------------------------------------------------
/YOUKUAIHAOMUTOU.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # {你的名字}
55 |
56 | 1. 自我介绍：专注市场和运营的技术小白，希望通过此次共学对Arbiturm有基础的了解
57 | 2. 你认为你会完成本次残酷学习吗？没有足够的信息
58 |
59 | ## Notes
60 |
61 |
62 |
63 | ### 2024.12.10
64 |
65 | 第二次记录，第一次记录没有成功。
66 | 线正式做下自我介绍：我是Nann，有着十年相关的品牌市场相关的工作经历，加入区块链行业，已经是第5年了，一直从事市场运营相关的工作。
67 | 加入此次共学，是主要是意识到一些基础的技术相关的知识，对于行业内日常工作的重要性，希望自己能够坚持
68 |
69 | ### 2024.12.11
70 |
71 | 今天的学习内容其实还没有完成。但是先厚着脸皮打下卡。
72 | 明天继续。
73 |
74 | ### 2024.12.13
75 | 打卡打卡
76 |
77 | ### 2024.12.14
78 |
79 | 学习内容：
80 | 交互式欺诈证明
81 |
82 |
83 |
--------------------------------------------------------------------------------
/YuanboXie.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | ---
6 |
7 | # YuanBoXie
8 |
9 | 1. 自我介绍: Web3/AI研究员
10 | 2. 你认为你会完成本次残酷学习吗？：尽力而为
11 |
12 | ## Notes
13 |
14 |
15 |
16 | ### 2024.12.10
17 |
18 | 笔记内容
19 |
20 | ### 2024.12.10
21 |
22 |
23 |
--------------------------------------------------------------------------------
/a-super-cat.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # 志伟
55 |
56 | 1. 大家好，社区新人一枚，很高兴与大家一起学习，有一种大家大学期末考试前一起交流学习的感觉哈哈哈
57 | 2. 会完成的，闹钟已调好
58 |
59 | ## Notes
60 |
61 |
62 |
63 | ### 2024.12.10
64 |
65 | #### 为什么需要Arbitrum？
66 |
67 | 答：以太坊区块链大概每妙可以完成20到40个交易（以太坊所有的用户形成的交易次数）；当交易达到上限时剩下的用户就需要去竞争以使他们的交易被链打包进去，竞争也使打包的费用升高了（在区块链中，为交易支付的打包费用越高，则越可能会被“矿工”优先打包。）
68 |
69 | Arbitrum采用乐观Rollup策略，将大部分运算与存储任务移交至L1链下（即L2上）来优化成本。L2大多是运行在单台服务器，也就是排序器（Sequencer/Operator）上的一条链。这种方式在“区块链不可能三角”中舍弃了“去中心化”来换取TPS与成本上的优势，允许L2代替以太坊处理交易指令，从而降低成本（虽然排序器作为系统中枢带有中⼼化色彩，但在成熟度比较高的Rollup方案中，中心化排序器仅能实施交易审查等软性作恶⾏为，或者恶意宕机，但在理想状态的Rollup⽅案中，有相应的⼿段进⾏遏制（比如强制提款或排序证明等抗审查机制））。
70 |
71 | #### Arbitrum的原理
72 |
73 | 答：Arbitrum采用乐观Rollup，这意味着暗含一条信任假设：任意时刻⾄少有⼀个诚实的L2验证者节点。不主动验证提交过来的数据，乐观地认为这些数据没有问题。如果提交的数据有错误，L2的验证者节点会主动发起挑战。挑战过程可概括为可以概括为多轮互动式细分、单步证明。在细分环节，挑战双⽅先对有问题的交易数据进⾏多轮回合制细分，直⾄分解出有问题的那⼀步操作码指令，并进⾏验证。因没有通过验证的L2 Block不具备最终确定性，故验证不通过时排序器可以对这些Block进行回滚。一般而言被提交到Layer1上的L2数据无法回滚，可以具有最终确定性。
74 |
75 |
76 | ### 2024.12.11
77 |
78 | #### Layer2有哪些技术类型？
79 |
80 | 1. Channels通道（状态通道、支付通道）：这种方式概括起来为：在通道建立的时候要锁定一些资金，这个存款也作为虚拟的“押金”，这个通道允许交易双方在链下进行多次交易，当通道不再需要时，双方确认最终状态，并生成最终状态的签名。然后这个最终状态提交到区块链，区块链会进行签名验证和结算，正式关闭通道。
81 |
82 | 2. Sidechains 侧链：侧链使用自己的[共识机制](https://www.horizen.io/academy/consensus-mechanisms/)进行操作，是一条独立运行但可以跟主链互通的区块链。它提供了一条快速通道，于特定时候可以让资产可以在主链和侧链之间快速流通。但由于侧链是独立运行的，不受主链保护，所以它自己要负责维护安全。这需要消耗额外的算力或资源，例如 POS 或 POW 共识机制。目前以太坊比较知名的侧链解决方案主要为 xDai 和 Gnosis 链。这些侧链都为以太坊提供了高速通道。开发者可以利用这些侧链的免费节点来开发 dApp。
83 |
84 | 虽然侧链不需要向主链提交状态数据，但许多侧链仍然选择这样做，以利用更大、更去中心化的链的安全性。
85 |
86 | 3. Validiums：Validiums 与侧链类似，是一条独立运行的区块链，但与主链紧密连结，Validiums 使用的主要是零知识证明而不是传统的工作量证明或权益机制证明。但与zk-Rollup不同交易数据不存储在 Layer1 主链上，所以 Validium 可以在不暴露真实交易讯息的情况下，证明交易是有效且符合预设规则的。但是跟侧链一样，Validium 也有局限性。因为不依赖主链安全，需要自建共识层，对开发者的要求较高。智能合约支持也相对有限。简单来说，Validium 是介于侧链和 Layer2 Rollup 之间的技术。它与主链有连接桥梁，可以交互资产。但需要自行确保安全性。
87 |
88 | 4. Rollups：Rollup 是现今最热门的 Layer2 技术，基本概念是把交易资料打包后以 Rollup （打包整理）的形式提交到 Layer1，主要分为两种流派。
89 |
90 | * Optimistic Rollup:Optimistic Rollup 是目前使用最广泛的 Layer2 解决方案，代表项目有 Arbitrum、Optimism 等。优点是易于开发和部署，可以快速吸引应用，缺点是有一定欺诈风险，需要依赖经济机制防止。
91 | * zk-Rollup:zk-Rollup 使用称为零知识证明（ZK-proofs）来验证交易的真实性，这可用于改善区块链上的隐私，因为它允许在不泄露有关交易的敏感讯息的情况下，来进行验证交易，缺点是较不易开发，代表项目有 zkSync、Polygon zkEVM、Linea。零知识证明技术的出现，将有可能会成为企业未来的采用方案，因为它可以仅向第三方（用户）显示他们想要传达的讯息，同时安全地传输敏感数据。
92 |
93 | * 总结：整体来说，ZK rollups 可以带来更高的效率，但 Optimistic Rollup 和 ZK Rollup 之间最大的区别在于 Optimistic 可以与 EVM 直接兼容，因此 Layer1 上的任何可能在 Layer2 上都是可直接实现的。但是，为了解决 ZK rollups 的 EVM 兼容问题，后续也逐渐出现了 zkEVM 解决方案（例如：**[zkSync](https://zksync.io/)**、[Polygon zkEVM](https://polygon.technology/polygon-zkevm?fbclid=IwAR2U3DocnBaFDwFLjwSKuDGk4e7yRhH6M6OfgA8i2s6xFeF2j7KqDbzh6q4)、**[Scroll](https://scroll.io/)**）
94 |
95 | #### 欺诈证明过程
96 |
97 | Arbitrum 的方法基于对争议的剖析。如果 Alice 的断言涉及了 N 个执行步骤，那就让她曝光出两个各涉及 N/2 个步骤的断言，然后让 Bob 选择一个来挑战。这样一来，争议的规模就缩小了一半。这个过程持续进行，每一回合都将争议的规模缩小一半，直到争议的范围变成一个执行步骤。注意，直到此时为止，L1 引导合约都不必考虑实际上执行了什么。仅当争议被缩小到单个执行步骤时，L1 引导合约才需要理解这一步要执行什么指令，以及 Alice 对该步的断言是否为真，以此解决争议。
98 |
99 | 交互式证明背后的关键原理是，如果 Alice 和 Bob 有所争议，Alice 和 Bob 应尽可能做链下的工作来解决争议，而不是让 L1 合约承担负担。
100 |
101 | ### 2024.12.12
102 |
103 | #### Arbitrum One
104 |
105 | Arbitrum One是Arbitrum的旗舰链，建立在Optimistic Rollup技术之上。Arbitrum的架构有部分在L1上有部分在L2上，EthBridge 负责对 Arbitrum Rollup 协议进行仲裁，以及维护 Arbitrum rollup 在以太坊链上的收件箱和发件箱。Arbitrum 虚拟机（AVM）是 EthBridge 提供的功能，是 L1 和 L2 之间的网关。AVM 能够读取输入，并基于这些输入执行计算，从而产生输出。ArbOS 运行在 AVM 上，确保智能合约在 Arbitrum 链上执行。ArbOS 完全存在于 L2 上，并像在以太坊上一样运行 EVM 合约。
106 |
107 | #### Nitro
108 |
109 | Nitro是One的升级。升级版的Nitro费用更低，以太坊兼容性更好以及zk证明更加简洁。支持Nitro的关键创新可概括为四点：证明程序、以Geth为核心、实现执行与证明分开、交互式欺诈证明的Optimistic Rollup。
110 |
111 | Arbitrum 的旧方案方案是通过定制的 Arbitrum 虚拟机（AVM）来模拟 EVM，它的一些内部逻辑在EVM 不一致（例如Gas的计算），所以仅限于低级指令。而Geth则基本完全支持以太坊的数据结构、格式和虚拟机，所以可以实现以太坊高度兼容。其关于欺诈证明的代码会编译为wasm格式，可移植、体积小、加载快、并且兼容web。而且Nitro又对wasm格式进行了微调，让它更适合与链交互。
112 |
113 | 在WASM代码上进行Arbitrum的交互式欺诈证明，就取代了Arbitrum虚拟机（AVM）的架构，直接以标准的语言和工具来构建和编译。
114 |
115 | #### Nova
116 |
117 | Arbitrum Nova 是基于 AnyTrust 技术搭建的新链，专为游戏、社交应用程序和对成本更敏感的用例而设计。Nova 提供了 2 种数据发布方式，一种是像 Nitro 一样以 Calldata 的形式发布完整数据，另一种是发布 DACert 证明数据的可用性。
118 |
119 | Nova 的定序器将完整的数据集同时发送给所有 DAC 委员会的成员，委员会签名后把带有签名的证明返回给定序器，定序器收集到足够多的证明就能将它们聚合并创建有效的数据可用性证明（DACert），然后把 DACert 发布到主网。如果定序器没有收集到足够多的证明，Nova 会回退到 Rollup 模式（以 Calldata 形式发布数据到主网）。
120 |
121 | 相对于 One 而言，Nova 通过牺牲一定的安全性来提高性能，游戏社交类等需要高频交互的 Dapp 适合部署在 Nova 上。
122 |
123 |
124 |
125 |
--------------------------------------------------------------------------------
/happylucie.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | # {Lucie}
6 |
7 | 1. 程序员，社区新人，第一次参加这样的学习活动，非常期待！
8 | 2. 可以的，不懂就问
9 |
10 | ## Notes
11 |
12 |
13 |
14 | ### 2024.12.10
15 |
16 |
17 |
18 | ---
19 | timezone: Asia/Shanghai
20 | ---
21 |
22 | # {Lucie}
23 |
24 | 1. 程序员，社区新人，第一次参加这样的学习活动，非常期待！
25 | 2. 可以的，不懂就问
26 |
27 | ## Notes
28 |
29 |
30 |
31 | ### 2024.12.10
32 | #### Why Arbitrum?
33 | 以太坊如果想真正去中心化，就应该reasonably accessible for anyone。
34 | 所以，交易吞吐量注定不能太大。
35 |
36 | #### What's Arbitrum?
37 | 以太坊扩展解决方案套件，使得部署和使用去中心化应用更加容易。
38 | **Arbitrum Rollup** A protocol for scaling Ethereum smart contracts.
39 | **Arbitrum AnyTrust** A protocol for scaling Ethereum smart contracts even further, with a mild trust assumption.
40 | **Arbitrum Nitro** The node software that codifies the Rollup and AnyTrust protocols.
41 | **Arbitrum nodes** Machines that run Nitro in order to service and/or interact with an Arbitrum chain.
42 | **Arbitrum One** A public Rollup chain.
43 | **Arbitrum Nova** A public AnyTrust chain.
44 | **Arbitrum bridge** Let you move ETH and ERC-20 tokens between Ethereum, Arbitrum, and select Orbit chains.
45 | **Arbitrum Orbit** Let you run your own Rollup and AnyTrust chains.
46 | **Arbitrum Stylus** Let you write EVM-compatible smart contracts in Rust and any other language that compiles to Wasm.
47 |
48 | **核心特点**
49 | 1. 优化的扩展性
50 | 通过将大部分交易计算和数据存储移至 Layer 2，减轻以太坊主网的负担。
51 | 支持数千笔每秒的交易，而主网的吞吐量仅为数十笔。
52 | 2. 低费用的同时保证安全性
53 | 大幅降低了用户的交易成本，同时利用以太坊主网作为最终的安全保障层，任何争议都可以在以太坊主链上解决。
54 | 3. 与以太坊的高兼容性
55 | 兼容以太坊虚拟机（EVM），开发者无需修改代码即可部署现有的以太坊智能合约。
56 | 支持以太坊钱包和工具（如 MetaMask、Hardhat）。
57 | 4. 多链支持与灵活选择
58 | Arbitrum 支持多条链并行运行。在以太坊主网上，有2条 Arbitrum 链：一条 Arbitrum Rollup 链，称为**Arbitrum One**，一条 AnyTrust链，称为**Nova**;用户和开发人员可以选择适合他们的安全/交易成本需求的任何选项。
59 |
60 | **Optimistic Rollup**
61 | 乐观验证：默认情况下，Rollup 假设所有提交的交易都是有效的。如果有人发现有欺诈行为，可以发起挑战，系统会进行验证和纠正。
62 | 链下计算：大部分计算和数据处理在链下完成，仅将必要的数据和交易摘要提交到以太坊主链，大大减少了链上负载。
63 |
64 |
65 | ### 2024.12.11
66 | **Op Rollups 与 ZK Rollups**
67 | 1. ZK 所有人都能通过 PoW 认证来参与认证
68 | 2. OP 更倾向于选择一组值得信赖的认证者，监督整个打包交易的过程
69 |
70 | **欺诈证明**
71 | 欺诈证明是一种加密和协议机制，旨在在区块链系统中防止和处理潜在的错误或恶意行为。它通过允许参与者对某些不正确的计算结果提出挑战，并验证这些挑战是否成立，从而保护系统的安全性。
72 |
73 | 在 Arbitrum 中：
74 | 验证者提交交易的状态更新，如果其他验证者认为该状态更新不正确，他们可以生成欺诈证明来挑战这一更新。
75 | 验证机制会审查这一挑战，通过重新执行部分计算来验证谁是正确的
76 |
77 | 交互式欺诈证明的执行流程：
78 | 1. 断言提交
79 | 验证者（Proposer）在 Layer 1 上提交一个状态更新（即 Layer 2 的断言），描述交易如何从一个状态转移到另一个状态。
80 | 断言包括起始状态、最终状态，以及该状态转移的证明。
81 | 2. 发起挑战
82 | 如果另一验证者（Challenger）认为断言不正确，他们可以发起挑战，启动交互式欺诈证明过程。
83 | 挑战者的目标是证明某个具体步骤的计算是错误的。
84 | 3. 争议分解
85 | 二分法定位错误：
86 | 争议解决协议将整个断言的计算过程分解为多个步骤。
87 | 验证者和挑战者在 Layer 1 上交互，通过多轮的二分查找逐步缩小争议范围，直到定位到一个具体的计算步骤。
88 | 每次交互中，双方需要提交关于哪个部分计算是正确的声明，协议将持续缩小范围。
89 | 4. 单步验证
90 | 一旦缩小到单个计算步骤，系统会在 Layer 1 上重新执行这一步骤。大部分争议分解过程发生在L2链下，只有最终验证单步计算时才在 Layer 1 上执行
91 | 如果断言中的该步骤正确，则挑战失败，挑战者被罚款。
92 | 如果该步骤错误，则挑战成功，验证者被罚款，断言被撤销。
93 |
94 | ### 2024.12.12
95 | Arbitrum 详解 - One、Nitro、Nova
96 | https://community.dorahacks.io/t/arbitrum-one-nitro-nova/562
97 |
98 |
--------------------------------------------------------------------------------
/hechichu.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 |
55 | # {hechichu}
56 |
57 | 1. 自我介绍
58 | 第一次参加共学活动,大三理科学生
59 |
60 | 2. 你认为你会完成本次残酷学习吗？
61 | 可以的
62 |
63 | ## Notes
64 |
65 |
66 |
67 | ### 2024.12.10
68 |
69 | Arbitrum 简介
70 | 什么是 Arbitrum？
71 | Arbitrum 是一个为扩展以太坊而设计的技术套件，提供比以太坊更低成本、更快速度的交易环境，同时保留以太坊级别的安全性。其核心产品 Arbitrum Rollup 是一种乐观汇总（Optimistic Rollup）协议。
72 | 为什么需要 Arbitrum 来扩展以太坊？
73 | 以太坊虽然强大，但其每秒交易量（TPS）有限（约 20-40），当达到上限时，用户竞争会导致交易费用上升。这种限制是为了确保以太坊的去中心化性质，使节点运行成本相对可控。
74 |
75 | Arbitrum 简介
76 | 什么是 Arbitrum？
77 | Arbitrum 是一个为扩展以太坊而设计的技术套件，提供比以太坊更低成本、更快速度的交易环境，同时保留以太坊级别的安全性。其核心产品 Arbitrum Rollup 是一种乐观汇总（Optimistic Rollup）协议。
78 |
79 | 为什么需要 Arbitrum 来扩展以太坊？
80 | 以太坊虽然强大，但其每秒交易量（TPS）有限（约 20-40），当达到上限时，用户竞争会导致交易费用上升。这种限制是为了确保以太坊的去中心化性质，使节点运行成本相对可控。
81 |
82 | Arbitrum Rollup 的工作原理
83 | 乐观执行：
84 | Arbitrum Rollup 通过将链上的大部分计算和存储转移到链下，降低以太坊主链（L1）的负担。主链假设 Arbitrum 上的活动是合法的，只有在发现违规时才会通过争议解决机制回到 L1 证明欺诈。
85 |
86 | 数据透明性：
87 | 所有交易数据都会被发布到以太坊主链上，即使出现争议，也能通过这些数据验证欺诈行为，从而继承以太坊的安全性。
88 |
89 | 验证者机制：
90 | 验证者推动 Arbitrum 链的状态更新，并在发现欺诈时提出争议。只要有一个诚实的验证者，链的安全性就能得到保障。
91 |
92 |
93 | 用户体验与开发者优势
94 | 与以太坊兼容：
95 | 用户可以使用熟悉的以太坊钱包与 Arbitrum 交互，开发者也能使用现有的以太坊工具部署智能合约。
96 |
97 | 更高效的交易处理：
98 | Arbitrum 通过批量提交交易和数据压缩等技术，大幅降低了交易成本。
99 |
100 | 扩展性：
101 | 除了 Rollup，Arbitrum 还提供 AnyTrust 链 和 Orbit 链：
102 |
103 | AnyTrust 链适用于不需要完全去中心化的应用，提供更低成本。
104 | Orbit 链允许开发者创建自己的链，进一步扩展应用场景。
105 |
106 |
107 | Arbitrum 简介
108 | 什么是 Arbitrum？
109 | Arbitrum 是一个为扩展以太坊而设计的技术套件，提供比以太坊更低成本、更快速度的交易环境，同时保留以太坊级别的安全性。其核心产品 Arbitrum Rollup 是一种乐观汇总（Optimistic Rollup）协议。
110 |
111 | 为什么需要 Arbitrum 来扩展以太坊？
112 | 以太坊虽然强大，但其每秒交易量（TPS）有限（约 20-40），当达到上限时，用户竞争会导致交易费用上升。这种限制是为了确保以太坊的去中心化性质，使节点运行成本相对可控。
113 |
114 | Arbitrum Rollup 的工作原理
115 | 乐观执行：
116 | Arbitrum Rollup 通过将链上的大部分计算和存储转移到链下，降低以太坊主链（L1）的负担。主链假设 Arbitrum 上的活动是合法的，只有在发现违规时才会通过争议解决机制回到 L1 证明欺诈。
117 |
118 | 数据透明性：
119 | 所有交易数据都会被发布到以太坊主链上，即使出现争议，也能通过这些数据验证欺诈行为，从而继承以太坊的安全性。
120 |
121 | 验证者机制：
122 | 验证者推动 Arbitrum 链的状态更新，并在发现欺诈时提出争议。只要有一个诚实的验证者，链的安全性就能得到保障。
123 |
124 | 用户体验与开发者优势
125 | 与以太坊兼容：
126 | 用户可以使用熟悉的以太坊钱包与 Arbitrum 交互，开发者也能使用现有的以太坊工具部署智能合约。
127 |
128 | 更高效的交易处理：
129 | Arbitrum 通过批量提交交易和数据压缩等技术，大幅降低了交易成本。
130 |
131 | 扩展性：
132 | 除了 Rollup，Arbitrum 还提供 AnyTrust 链 和 Orbit 链：
133 |
134 | AnyTrust 链适用于不需要完全去中心化的应用，提供更低成本。
135 | Orbit 链允许开发者创建自己的链，进一步扩展应用场景。
136 |
137 | 当前的 Arbitrum 产品
138 | Arbitrum One：一个 Rollup 链，强调去中心化和安全性。
139 | Nova：一个 AnyTrust 链，适合需要高吞吐量、低费用的应用。
140 | 此外，开发者可以基于 Arbitrum 的技术栈（如 Nitro 和 Stylus）创建高性能的智能合约，甚至使用如 Rust、C++ 等编程语言。
141 |
142 | ### 2024.12.11
143 | ### Arbitrum 概述
144 |
145 | Arbitrum 是一套以太坊扩容解决方案，旨在简化去中心化应用的构建和使用。其提供了多个协议、链、服务和 SDK，支持 Arbitrum 生态系统的运行。
146 |
147 | #### Arbitrum 组件：
148 | 1. **Arbitrum Rollup**
149 | - 用于扩展以太坊智能合约的协议。
150 |
151 | 2. **Arbitrum AnyTrust**
152 | - 更进一步扩展以太坊智能合约的协议，采用轻度信任假设。
153 |
154 | 3. **Arbitrum Nitro**
155 | - 实现 Rollup 和 AnyTrust 协议的节点软件。
156 |
157 | 4. **Arbitrum 节点**
158 | - 运行 Nitro 软件的机器，用于服务或与 Arbitrum 链交互。
159 |
160 | 5. **Arbitrum One**
161 | - 公共的 Rollup 链。
162 |
163 | 6. **Arbitrum Nova**
164 | - 公共的 AnyTrust 链。
165 |
166 | 7. **Arbitrum 桥接**
167 | - 支持在以太坊、Arbitrum 和部分 Orbit 链之间转移 ETH 和 ERC-20 代币。
168 |
169 | 8. **Arbitrum Orbit**
170 | - 支持运行自定义的 Rollup 和 AnyTrust 链。
171 |
172 | 9. **Arbitrum Stylus**
173 | - 支持用 Rust 或其他编译成 Wasm 的语言编写与 EVM 兼容的智能合约。
174 |
175 | #### Arbitrum 面向用户：
176 | - **Arbitrum 桥接**
177 | - 用户可以通过 Arbitrum 桥接在以太坊、Arbitrum 和部分 Orbit 链之间转移 ETH 和 ERC-20 代币。
178 |
179 | - **Arbitrum Portal**
180 | - 提供一个 Arbitrum 上 DApp 的目录。
181 |
182 | - **快速入门（桥接）**
183 | - 为第一次使用桥接的用户提供逐步指导。
184 |
185 | #### Arbitrum 面向开发者：
186 | - **Arbitrum 简介**
187 | - Arbitrum 扩容解决方案的技术介绍。
188 |
189 | - **快速入门（Solidity）**
190 | - 针对 Web2 开发者，帮助其将 Solidity 智能合约部署到 Arbitrum。
191 |
192 | - **快速入门（Rust）**
193 | - 针对 Web3 开发者，帮助其使用 Stylus 将 Rust 智能合约部署到 Arbitrum。
194 |
195 | #### Arbitrum 面向节点运行者：
196 | - **运行完整节点**
197 | - 帮助节点运行者在不依赖第三方节点的情况下访问 Arbitrum 链。
198 |
199 | - **配置数据可用性委员会**
200 | - 面向数据可用性委员会成员和 Orbit 链运营者，帮助其运行数据可用性服务器。
201 |
202 | #### Arbitrum 面向链运营者：
203 | - **Orbit 简介**
204 | - 为有意了解 Orbit 价值主张和使用场景的读者提供的内容。
205 |
206 | - **Orbit 快速入门**
207 | - 帮助链运营者使用 Arbitrum Orbit 部署其第一个 Arbitrum 链。
208 |
209 | #### 技术原理：
210 | - **Nitro 内部架构**
211 | - 对 Nitro 架构的技术深入分析。
212 |
213 | - **AnyTrust 协议内部**
214 | - 对 AnyTrust 协议的技术深入分析。
215 |
216 | - **Arbitrum 白皮书**
217 | - 介绍 Nitro 的原始白皮书。
218 |
219 | - **DAO 文档**
220 | - 支持 Arbitrum DAO 成员的文档。
221 |
222 | ### 2024.12.12
223 | ### Rollup 学习笔记
224 |
225 | **1. 什么是 Rollup**
226 |
227 | Rollup 的核心是“归纳整理”，目的是缓解以太坊网络拥堵、提高 TPS（每秒交易量）并降低 Gas 费用。它的工作原理是将以太坊上的计算任务转移到 Layer 2 层协议进行处理，将计算结果压缩后再返回以太坊主网。
228 |
229 | Rollup 类比：
230 | 就像节假日景区的排队问题，平日直接排队效率较低，但节假日通过可信赖的代表来集中处理问题，可显著提升效率。
231 |
232 | 主要作用：
233 | - 将大量交易签名压缩成一个“VIP”签名块。
234 | - 提升以太坊网络的吞吐量与运行效率。
235 | - 同时保留链上部分数据以保障安全性。
236 |
237 | Rollup 的两种主要实现方式为 **ZK Rollups** 和 **Optimistic Rollups**，它们分别有不同的特点和应用场景。
238 |
239 | ---
240 |
241 | **2. 什么是 ZK Rollups**
242 |
243 | **ZK Rollups** 利用零知识证明技术（ZK-SNARK），通过 Layer 2 验证者进行交易真实性认证，并将结果压缩后返回以太坊。
244 |
245 | ZK 的四大特点：
246 | 1. **Zero Knowledge**：无需查看完整交易数据即可验证交易。
247 | 2. **Succinct**：认证过程简洁高效。
248 | 3. **Non-Interactive**：验证无需交互。
249 | 4. **Argument of Knowledge**：确保数据的真实性和正确性。
250 |
251 | **优点**：
252 | - 验证速度快，可快速将 Layer 2 的资产转回 Layer 1。
253 | - 适合支付、银行和交易所等快速结算业务。
254 |
255 | **缺点**：
256 | - 算法复杂，对开发者有较高的技术门槛。
257 |
258 | ---
259 |
260 | **3. 什么是 Optimistic Rollups**
261 |
262 | **Optimistic Rollups** 采取“乐观假设”的方式，默认所有交易都是可信的，并由验证者通过奖惩机制发现和处理异常。
263 |
264 | 工作原理：
265 | 验证者需要质押代币作为保证金，若其他验证者发现问题，可通过欺诈证明对其进行罚款。
266 |
267 | **优点**：
268 | - 开发友好，适合迁移原本在 Layer 1 的 Dapp 项目。
269 | - 具有智能合约功能，可通过相应的治理代币进行治理。
270 |
271 | **缺点**：
272 | - 从 Layer 2 提币到 Layer 1 速度较慢（通常需要 1 周以上）。
273 | - 存在验证者作恶的潜在风险。
274 |
275 | ---
276 |
277 | **4. 什么是 Arbitrum**
278 |
279 | Arbitrum 是基于 Optimistic Rollups 的 Layer 2 协议项目，目前 TVL（总锁仓价值）位居前列。与 Optimism 项目相比，Arbitrum 采用多轮欺诈证明，更加高效，并且具有自己的虚拟机，增强了与以太坊网络的兼容性。
280 |
281 | ---
282 |
283 | **总结**：
284 | - **Rollup**：通过将任务“外包”给 Layer 2，提升以太坊运行效率。
285 | - **ZK Rollups**：基于零知识证明算法，适合支付类业务，验证速度快但算法复杂。
286 | - **Optimistic Rollups**：通过默认信任和奖惩机制，适合 Dapp 和 DeFi 项目，提币速度较慢。
287 | - **Optimism 和 Arbitrum**：两者都属于基于 Optimistic Rollups 的协议项目，适配不同场景需求。
288 | - **ZKSync**：基于 ZK Rollups 的典型项目之一。
289 |
290 | ZK Rollups 未来潜力大，但目前 Optimistic Rollups 更适合 Dapp 生态发展。
291 |
292 | ### 2024.12.13
293 | ### 挑战机制笔记
294 |
295 | #### 区块挑战
296 | 1. **起始阶段**：挑战从全局状态（包括区块哈希）开始进行二分操作。
297 | 2. **缩小范围**：在实际的机器执行争议之前，争议会逐步缩小到单个区块。
298 | 3. **执行挑战**：当争议缩小到单个区块后，当前响应者可以调用 `challengeExecution`。
299 | - 这类似于二分操作，响应者需提供一个竞争的全局状态和机器状态。
300 | - 根据这些信息，挑战会进入具体的执行挑战阶段。
301 |
302 | #### 执行挑战
303 | 1. **单步执行验证**：当争议被进一步缩小到单步执行时，当前响应者可以调用 `oneStepProveExecution`。
304 | 2. **证明步骤**：响应者需提供执行机器某一步所需的证明数据。
305 | - 如果执行该步骤后结果状态与之前声明的状态不一致，当前响应者胜出挑战。
306 |
307 | #### 通用二分协议
308 | 1. **定义**：协议中的“二分”泛指对任意程度的切分。
309 | 2. **挑战过程**：
310 | - 使用 `ChallengeLib` 的 `hashChallengeState` 方法计算挑战状态哈希（`challengeStateHash`），其基于分段哈希列表、起始位置和总段数长度。
311 | - 每段的步数距离为 `floor(segmentsLength / degree)`，最后一对段则加上 `segmentsLength % degree`，确保总步数一致。
312 | 3. **初始阶段**：
313 | - 挑战以两个分段（程度为 1）开始，即提出者的初始声明。
314 | - 挑战者回合中，需选择相邻的一对分段进行质疑，并提供与第二段不同的结束分段，将挑战进一步细化。
315 | 4. **递进规则**：
316 | - 每次二分的最大程度为 `min(40, numStepsInChallengedSegment)`，确保挑战持续推进。
317 | - 长度为 1 步的分段无法继续二分，此时挑战具体进入 `challengeExecution` 或 `oneStepProveExecution`。
318 |
319 | 5. **对称性**：与传统二分协议不同，双方轮流选择挑战位置并在质疑时提出二分。
320 |
321 | #### 获胜条件
322 | 1. **胜利机制**：当前响应者胜出后，挑战状态哈希被设置为 0，对手无法继续有效操作，最终超时失败。
323 | 2. **延时胜利**：胜利不是即时的，此设计用于在挑战结果出错时，可以通过合约升级解决问题。
324 |
325 | ### 2024.12.14
326 | ### Arbitrum One 笔记：交互式证明及设计核心
327 |
328 | #### **Arbitrum 的设计背景**
329 | 1. **Optimistic Rollups 的争议解决方式**
330 | - 两种方法：交互式证明和重执行交易。
331 | - Arbitrum 采用交互式证明，注重效率与灵活性。
332 |
333 | 2. **历史发展**
334 | - 2014 年开始开发交互式欺诈证明。
335 | - 核心机制发表于 2018 年，现已进行多次升级。
336 |
337 | ---
338 |
339 | #### **交互式证明（Interactive Proofs）**
340 | 1. **基本原理**
341 | - 通过 L1 合约引导，Alice 和 Bob 参与回合制协议以缩小争议范围。
342 | - 如果 N 步执行步骤有争议，Alice 将其分为两部分，Bob 挑战其中一部分。
343 | - 争议逐步缩小到单步指令，由 L1 合约验证单步断言的正确性。
344 |
345 | 2. **优势**
346 | - **链下处理优先**：Alice 和 Bob 在链下尽量解决分歧，降低 L1 合约负担。
347 | - **效率高**：大多数争议处理都无需在链上模拟执行完整交易。
348 |
349 | ---
350 |
351 | #### **重执行交易（Re-execution of Transactions）**
352 | 1. **方法描述**
353 | - 每笔交易附带状态哈希值断言。
354 | - 在争议中，L1 合约模拟完整交易以验证结果。
355 |
356 | 2. **局限性**
357 | - L1 合约需要更多计算资源。
358 | - 受限于以太坊的交易 Gas Limit 和区块容量。
359 |
360 | ---
361 |
362 | #### **交互式证明的优势**
363 | 1. **乐观情形下的高效**
364 | - 一个 Rollup 区块只需一个状态断言，节省 L1 区块空间。
365 | - 相比重执行方法，减少状态断言的存储和验证成本。
366 |
367 | 2. **悲观情形下的高效**
368 | - 仅需检查争议步骤是否正确缩小，而非模拟完整交易。
369 | - L1 合约开销更低，仅需验证单步指令。
370 |
371 | 3. **突破 Gas Limit**
372 | - 允许 Gas 消耗较大的交易，适应更复杂的操作。
373 | - 重执行模式无法支持超过以太坊区块 Gas Limit 的交易。
374 |
375 | 4. **合约大小无限制**
376 | - 无需为每个 L2 合约创建对应的以太坊合约。
377 | - 合约大小可超出以太坊限制。
378 |
379 | 5. **更高的实现弹性**
380 | - 支持 EVM 尚未定义的新指令。
381 | - 不受限于 EVM 的原生功能，适配性更强。
382 |
383 | ---
384 |
385 | #### **Arbitrum 的设计核心**
386 | 1. **交互式证明的驱动作用**
387 | - Arbitrum 的许多设计特性为支持交互式证明而存在。
388 | - **思考方向**：
389 | - 该功能是否支持交互式证明？
390 | - 如何利用交互式证明实现？
391 |
392 | 2. **总结**
393 | - 交互式证明是 Arbitrum 整体架构的核心，贯穿其设计的方方面面。
394 |
395 |
--------------------------------------------------------------------------------
/iavl.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | # Albert
6 |
7 | 1. I am a blockchain developer, and I want to gain a deeper and more comprehensive understanding of Arbitrum through this course.
8 |
9 | ## Notes
10 |
11 |
12 |
13 | ### 2024.12.10
14 |
15 | 笔记内容
16 |
17 | ### 2024.12.10
18 |
19 |
20 |
--------------------------------------------------------------------------------
/jiejie.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | # {jiejie}
9 |
10 | 1. 您好，我是大四学生一枚，目前技术栈html，css，JavaScript，vue，mysql。目标是找到web3领域的工作，深耕这个领域直至开花结果。感谢提供学习帮助，谢谢！
11 | 2. 你认为你会完成本次残酷学习吗？
12 | 3. 会
13 | ## Notes
14 |
15 |
16 |
17 | ### 2024.12.10
18 |
19 | 笔记内容
20 |
21 | ### 2024.12.10
22 |
23 |
24 |
--------------------------------------------------------------------------------
/jjeejj.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # {你的名字}
55 |
56 | 1. Iyi[奕] 一名后端开发者 golang、Node.js、进入 web3 行业 2年
57 | 2. 你认为你会完成本次残酷学习吗？ 会
58 |
59 | ## Notes
60 |
61 |
62 |
63 | ### 2024.12.10
64 |
65 | 1. 学习 Arbitrum 基础介绍 https://docs.arbitrum.io/welcome/arbitrum-gentle-introduction
66 | 2. Arbitrum suite https://docs.arbitrum.io/welcome/get-started
67 |
68 | ### 2024.12.11
69 |
70 | 1. 阅读 Layer 2 技术类型 https://cloud.tencent.com/developer/news/1003179
71 | 2. 初步了解交互式证明
72 | > 有种是懂非懂的感觉,理解不是跟透彻, 期望有人可以通俗易懂的讲解一下
73 |
74 | ### 2024.12.12
75 |
76 | 1. 阅读官方文章 简单了解下 Classic 和 Nitro 区别 https://arbitrum.io/nitro-vs-classic/
77 |
78 | ### 2024.12.13
79 |
80 | 1. 进一步学习 One、Nitro、Nova 详解 https://community.dorahacks.io/t/arbitrum-one-nitro-nova/562
81 |
82 | ### 2024.12.14
83 |
84 | 1. 阅读学习 深入理解 Arbitrum 文章 https://www.theblockbeats.info/news/26507
85 |
86 | ### 2024.12.15
87 |
88 | 1. 简单了解下 Arbitrum 生态 [Messari：深度分析 Arbitrum 的繁荣生态](https://www.theblockbeats.info/news/35982)
89 |
90 | ### 2024.12.16
91 |
92 | 1. 阅读 $ARB 代币概述文章 https://docs.arbitrum.foundation/concepts/arb-token
93 |
94 | ### 2024.12.17
95 |
96 | 1. 全览 Arbitrum 上百个生态项目 http://www.yuanli24.com/news/11836 生态庞大
97 |
98 | ### 2024.12.18
99 |
100 | 1. 代币流通供应量 https://docs.arbitrum.foundation/token-supply
101 |
102 | ### 2024.12.19
103 |
104 | 1. ARB 经济模型详解 https://foresightnews.pro/article/detail/28817
105 |
106 | ### 2024.12.20
107 |
108 | 1. DAO 术语表 https://docs.arbitrum.foundation/dao-glossary
109 |
110 | ### 2024.12.21
111 |
112 | 1. DAO 治理案例分析 https://foresightnews.pro/article/detail/45035
113 | 1. 做好项目
114 | 2. 积极参与生态中的活动
115 | 3. TVL 仍是一个非常重要的指标
116 |
117 | ### 2024.12.22
118 |
119 | 1. Arbitrum Orbit 生态探索 https://www.techflowpost.com/article/detail_15657.html
120 |
121 | ### 2024.12.23
122 |
123 | 1. 如何提交提案 https://docs.arbitrum.foundation/how-tos/create-submit-dao-proposal
124 |
125 | ### 2024.12.24
126 |
127 | 1. 治理理念 https://docs.arbitrum.foundation/concepts/arbitrum-dao
128 |
129 | ### 2024.12.25
130 |
131 | 1. 治理架构 https://docs.arbitrum.foundation/security-council-members
132 |
133 | ### 2024.12.26
134 |
135 | 1. 代币经济、机构成本、估值分析 https://foresightnews.pro/article/detail/28668
136 |
137 | ### 2024.12.27
138 |
139 | 1. 官方治理文档 https://docs.arbitrum.foundation/gentle-intro-dao-governance
140 |
141 | ### 2024.12.28
142 |
143 | 1. 提供的资料基本学习完了，对 Arbitrum 有了基本的了解，知道是什么，解决了什么问题，有什么优势，以及如何去使用
144 | 2. 后续 阅读开发文档 尝试再 arbitrum 上进行 Dapp 开发
145 |
146 | ### 2024.12.29
147 |
148 | 1. 阅读 开发文档的 welcome 部分，了解 chain 相关的信息
149 |
150 | ### 2024.12.30
151 |
152 | 1. 今天收官，对自己一个总结：总的来说 有收获，系统的学习 Arbitrum, 对自己 all in Web3 行业打基础
153 |
154 |
155 |
--------------------------------------------------------------------------------
/joyc.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Tokyo
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # hython
55 |
56 | 1. Base Tokyo的web3从业者
57 | 2. 你认为你会完成本次残酷学习吗？可能会
58 |
59 | ## Notes
60 |
61 |
62 |
63 | ### 2024.12.10
64 | > [!NOTE]
65 | > A gentle introduction to [Arbitrum](https://docs.arbitrum.io/welcome/arbitrum-gentle-introduction)
66 | #### Arbitrum 简介
67 | - 一种扩展以太坊的技术套件，使交易更便宜、更快，同时保持以太坊级别的安全性。
68 | - 背景以太坊的局限性：每秒只能处理 20-40 笔交易，竞争导致费用上升。
69 |
70 | #### Arbitrum 的优化
71 | - Rollup 的工作原理
72 | 作为以太坊的子模块运行，遵循“无罪推定”，必要时回到 L1 解决争议，保持安全性。
73 | - 交易效率的提升
74 | 批量提交交易，数据压缩存储在 L1，显著降低费用。
75 |
76 | #### 安全与信任
77 | - 验证者的角色
78 | 提供状态声明、处理争议，任何人都可以运行验证者以确保系统无需信任。
79 | - 欺诈检测
80 | 通过缩小到单一计算步骤解决争议，确保诚实方获胜。
81 |
82 | #### 用户体验
83 | - 兼容性
84 | 支持现有以太坊工具，提供类似以太坊的使用体验，但成本更低、速度更快。
85 | - 快速提现
86 | 使用快速桥接应用可避免 1 周延迟。
87 |
88 | #### 技术扩展
89 | - Stylus 新功能
90 | 支持 Rust 和 C++ 等高性能智能合约语言，提供更大灵活性。
91 | - AnyTrust 链的优势
92 | 数据离链存储，费用更低，适用于高吞吐量但去中心化要求较低的场景。
93 |
94 | #### 多链选择
95 | - 现有链
96 | - *Arbitrum One*：Rollup 链，去中心化、安全性高。
97 | - *Nova*：AnyTrust 链，费用低。
98 | - Orbit 链
99 | 开发者可构建自定义 Arbitrum 链。
100 |
101 | #### 决策机制
102 | - Arbitrum One 和 Nova 的未来由治理系统决定。
103 |
104 | ### 2024.12.11
105 | > [!NOTE]
106 | > 轻松理解Rollup，ZK Rollups与Optimistic，Arbitrum的[区别](https://cloud.tencent.com/developer/news/1003179)
107 |
108 | #### Rollup
109 | 是一种交易整理方法，将交易任务外包至 Layer2 协议执行，从而提升以太坊网络的效率与 TPS。
110 |
111 | #### ZK Rollups
112 | - **特点**：
113 | 1. 零知识证明：无需查看完整数据即可验证。
114 | 2. 简洁算法：验证过程简练高效。
115 | 3. 非交互性：验证者身份无需公开。
116 | 4. 数据真实性保障：通过复杂算法确保验证结果可靠。
117 | - **优点**：
118 | - 提币到 Layer1 快速，适合支付和快速结算场景。
119 | - **缺点**：
120 | - 算法复杂，对开发者有一定技术门槛。
121 |
122 | #### Optimistic Rollups
123 | - **特点**：
124 | 1. 默认信任所有交易有效，后续验证期间通过奖惩机制处理错误。
125 | 2. 支持智能合约和项目迁移，兼容性强。
126 | - **优点**：
127 | - 开发 Dapp 方便，支持无缝迁移项目。
128 | - **缺点**：
129 | - 提币速度慢（通常需一周），存在验证者作恶风险。
130 |
131 | #### Optimism与Arbitrum对比
132 | - 共同点：基于 Optimistic Rollups 开发，专注提升以太坊扩容性能。
133 | - 区别：
134 | - **Optimism**：一次欺诈验证，交易计算依赖 Layer1 执行。
135 | - **Arbitrum**：多轮欺诈验证，交易执行在独立虚拟机中完成，更兼容 ETH 网络。
136 |
137 | #### 其他Layer2方案
138 | - **Zksync**：基于 ZK Rollups 方法，专注快速支付场景。
139 | - **Plasma、Metis**：其他 Layer2 协议，探索不同扩容方式。
140 | - **Truebit**：结合博弈与 AI，提升以太坊计算效率。
141 |
142 | #### 总结
143 | - **Rollup** 是以太坊扩容的核心思路。
144 | - **ZK Rollups**：适合支付类业务，验证严谨但开发难度较高。
145 | - **Optimistic Rollups**：适合 Dapp 和 Defi，但提币速度较慢。
146 | - **Optimism 与 Arbitrum**：基于乐观归纳的 Layer2 代表项目，各有优势与特性。
147 |
148 | ### 2024.12.12
149 | > [!NOTE]
150 | > Arbitrum 欺诈证明机制详解 [文档](https://docs.arbitrum.io/how-arbitrum-works/fraud-proofs/challenge-manager)
151 |
152 | #### 欺诈证明详解
153 | 1. 挑战的开始
154 | - 一个断言（Assertion）在链上被创建，声称某个 Arbitrum 节点在特定时间段内从一个状态转换到另一个状态。如果此断言被质疑，挑战开始。挑战通过对全局状态（包括区块哈希）进行二分开始。
155 | - 在执行有争议的 L2 交易之前，争议首先被缩小到特定的 L2 区块（含多个 L2 交易）。这个过程被称为“争议二分”(Dissection of Dispute)，通过对一系列 L2 区块的哈希链进行二分查找来确定有争议的 L2 区块。
156 |
157 | 2. 执行挑战机制
158 | - 在确定到具体包含争议交易的区块后，攻击者（Challenger） 可以调用 challengeExecution 发起执行挑战。
159 | - 被挑战者（Defender） 需提供与此区块执行相关的竞争性的全局状态和机器状态断言，以推进到执行挑战阶段。
160 | - 具体来说，Defender 需要将有争议的 L2 区块分解成多个 One-Step Proof（单步证明），并创建一个 Assertion 树，用于后续的执行二分。
161 |
162 | 3. 单步执行验证
163 | - 当挑战缩小到单步执行时，攻击者 可调用 oneStepProveExecution 质疑 Defender 提供的某一个单步证明。
164 | - 被挑战者 需提供证明数据来执行机器的单步操作 (包括操作码、操作数、内存状态等)。
165 | - 如果执行结果与先前断言的状态不符，攻击者 即赢得挑战。反之，如果被挑战者提供的单步证明通过了验证，则攻击者输掉挑战，并受到惩罚。
166 |
167 | 4. 通用二分协议
168 | - 在确定了包含争议交易的 L2 区块后，挑战将围绕该区块的执行展开，这部分挑战遵循通用的二分协议。
169 | - 挑战从仅包含两个片段的初始断言（一个度数）开始，由挑战方发起。这里的“片段”可以理解为 L2 区块执行过程中的一段。一个片段对应多个 AVM 指令。
170 | - 每轮中，被挑战者 (Defender) 需选择相邻片段进行质疑，并提供新的二分，进一步缩小争议范围。这意味着被挑战者需要将有争议的片段继续进行二分，直到争议被缩小到单个 AVM 指令。
171 | - 最小度数为 40 或挑战片段步长。步长为 1 的片段不能再二分。这意味着，最小的争议片段可以包含 40 个 AVM 指令，如果某个片段的步长（包含的 AVM 指令数）小于等于 40，它就不能被继续二分。
172 |
173 | 5. 挑战逻辑对称性 ♟️
174 | - 与传统乐观 Rollup 的单边挑战协议不同，该协议中双方轮流选择挑战点并提出二分，双方在挑战过程中的权利和义务是对等的。这意味着攻击者和被挑战者可以相互质疑对方的断言，直到最终确定争议所在。
175 |
176 | 6. 胜利条件
177 | - 胜利不是即时的；当前占优的一方 成为胜者，对方没有有效动作后将通过超时失败。
178 | - 这是一种保护措施，以便在错误解决的情况下可以升级合约修复问题。这意味着即使一方在当前挑战中获胜，也需要等待一段时间才能最终确认胜利，这为合约升级留出了时间窗口。
179 |
180 | 7. 辅助库功能
181 | - ChallengeLib 提供了 hashChallengeState 方法，可生成挑战状态哈希，包含片段哈希列表、起始位置和总片段长度等信息。这有助于验证挑战状态的一致性。
182 | - 此外，ChallengeLib 还提供了 bisectExecution (执行二分)、computeOneStepProofHash (计算单步证明哈希) 等方法，用于支持欺诈证明的各个阶段。
183 |
184 | #### 补充说明:
185 | - Arbitrum 使用 AVM (Arbitrum Virtual Machine) 作为其虚拟机，与 EVM 部分兼容。
186 | - 欺诈证明的目的是确保 Arbitrum 链上状态的正确性。如果验证者发布了错误的状态，任何人都可以通过发起挑战来证明其欺诈行为。
187 | - Arbitrum 的欺诈证明机制是交互式的，需要在链上进行多轮交互才能完成。
188 | - 该机制的安全性基于密码学假设和博弈论，能够激励验证者诚实地执行交易。
189 |
190 | #### 总结:
191 | Arbitrum 的欺诈证明机制是一个复杂而精妙的系统，它通过多轮交互式的二分协议，将争议逐步缩小到单个 AVM 指令的执行，最终确定状态转换的正确性。这种机制结合了密码学证明和博弈论，确保了 Arbitrum 链的安全性和可扩展性。
192 |
193 |
194 |
195 | ### 2024.12.13
196 | > [!NOTE]
197 | > Arbitrum [交互式欺诈证明](https://medium.com/offchainlabs/interactive-fraud-proofs-arbitrums-secret-sauce-debc3b019418)
198 | #### 交互式欺诈证明的原理
199 |
200 | 交互式欺诈证明的核心思想在于，**不在链上执行所有的计算，而是仅在出现争议时才进行验证，并且通过多轮交互，逐步缩小争议范围，最终只在链上执行最少量的必要计算。** 这是一种“按需验证”的模式，极大地提升了效率。
201 |
202 | 传统的欺诈证明可能需要在链上重新执行整个计算过程以验证结果，这非常耗费资源。而交互式欺诈证明通过“挑战-回应”的机制，将复杂的计算验证过程分解为一系列简单的步骤，每次只在链上执行一部分，从而大幅降低了以太坊主链的负担。
203 |
204 | **关键概念：**
205 |
206 | * **链下执行：** 大部分计算在链下进行，速度快且成本低。
207 | * **争议：** 当有人认为链下计算的结果不正确时，会发起争议。
208 | * **二分搜索：** 争议发起后，双方会逐步将争议范围缩小，类似于二分查找算法，每一次交互都将争议范围减半。
209 | * **链上验证：** 只有在争议范围被缩小到最小后，才在链上执行最终的、极小部分的计算进行验证。
210 |
211 | #### 交互式欺诈证明的执行步骤
212 |
213 | 1. **链下计算：** 验证器（Validator）在链下执行智能合约，并生成一个状态承诺（State Commitment），即计算结果的摘要，并将其提交到以太坊主链。
214 | 2. **争议发起：** 如果有人（挑战者）认为验证器提交的状态承诺不正确，则会发起争议（Challenge）。
215 | 3. **二分交互（多轮）：**
216 | * **初始挑战：** 挑战者指出验证器提交的状态承诺的哪个部分可能有错误。
217 | * **范围缩小：** 验证器回应，提供更多关于计算过程的细节，缩小有争议的计算范围。
218 | * **反复迭代：** 挑战者和验证器之间会进行多轮交互，双方轮流指出或解释计算过程中的细节，不断缩小争议范围。
219 | * **关键点：** 每一次交互都将有争议的计算范围减半，直到最后只剩下一个最小的计算步骤。
220 | 4. **链上验证：** 最终，争议被缩小到一个非常具体的计算步骤，这部分计算将被放在以太坊主链上执行，以确定是否真的存在欺诈。
221 | 5. **仲裁：** 如果链上执行结果与验证器声称的结果不符，则判定验证器存在欺诈，并将惩罚该验证器。如果链上执行结果与验证器声称的结果一致，则判定挑战者存在错误，并惩罚挑战者。
222 |
223 | **比喻：**
224 |
225 | 这个过程类似剪刀石头布游戏：
226 |
227 | * **验证器：** 就像玩家“宣称”自己出了剪刀，但实际上可能出了石头。
228 | * **挑战者：** 就像玩家质疑对方“宣称”的结果，并试图找出对方作弊的证据。
229 | * **二分交互：** 双方在游戏的过程中会不断地“试探”，逐步暴露双方的策略，最终将作弊的可能性缩小到最小。
230 |
231 | 通过这种多轮交互，Arbitrum 能够在保持以太坊安全性的前提下，大幅提高交易速度和降低交易成本。
232 |
233 |
234 |
235 |
236 |
--------------------------------------------------------------------------------
/linyuanye3.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | # {jiejie}
9 |
10 | 1. 您好，我是大四学生一枚，目前技术栈html，css，JavaScript，vue，mysql。目标是找到web3领域的工作，深耕这个领域直至开花结果。感谢提供学习帮助，谢谢！
11 | 2. 你认为你会完成本次残酷学习吗？会
12 | ## Notes
13 |
14 |
15 |
16 | ### 2024.12.10
17 |
18 | ARB是一种稳定币，用于治理ARB社区，全程Arbitrum，通过将以太坊的交易从主链转移到侧链，从而提升性能，降低交易费率和 拥挤度。兼容以太坊虚拟机EVM，支持现有的以太坊智能合约和去中心化应用。
19 | 广泛应用于DeFi和游戏和NTF，企业应用等领域。
20 |
21 | ### 2024.12.12
22 | Arbitrum 是由 Offchain Labs 开发的一种以太坊二层扩容解决方案。它旨在通过将大量交易从以太坊主链转移到二层网络来提高交易速度并降低成本，同时仍保持以太坊的安全性和去中心化特性。
23 | 工作原理：采用 Optimistic Rollups 技术，允许用户在二层网络上进行交易，这些交易被打包成批次并定期提交到以太坊主链进行验证。在提交期间，交易被认为是 “乐观” 有效的，只有在出现争议时才会进行全面的验证。
24 |
25 | ### 2024.12.14
26 | Layer2 扩容方案：如 Optimistic Rollups 和 ZK Rollups 等技术中，用于验证链下交易批次的有效性。在 Optimistic Rollups 中，当有人对提交到主链的交易批次提出质疑时，就会通过交互式欺诈证明来确定该批次是否存在欺诈行为。
27 |
28 | ### 2024.12.15
29 | 应用场景
30 | 去中心化金融：在去中心化金融领域，Arbitrum Layer2 可以支持各种金融应用，如借贷、交易、流动性挖矿等。用户可以在 Arbitrum 上以较低的成本进行快速交易，提高资金的使用效率。
31 | 游戏和 NFT：游戏和 NFT 市场对交易速度和成本非常敏感，Arbitrum Layer2 能够满足这些需求，为用户提供流畅的游戏体验和低成本的 NFT 交易环境。
32 | 智能合约开发：开发者可以在 Arbitrum Layer2 上开发和部署智能合约，利用其高可扩展性和低交易成本的优势，快速迭代和优化应用程序。
33 |
34 | ### 2024.12.16
35 | Arbitrum（ARB）
36 | 技术优势：
37 | 基于 Optimistic Rollup 技术，具有高吞吐量和低成本的特点。
38 | 与以太坊生态深度集成，支持智能合约和去中心化应用。
39 | 生态系统：
40 | 拥有丰富的 DeFi 生态，包括 Uniswap、Aave 等知名协议。
41 | 社区活跃，开发者支持力度大。
42 |
43 | ### 2024.12.17】
44 | 你好
45 |
46 | Arbitrum DAO：
47 | $ARB 代币持有者可以参与 Arbitrum DAO 的治理，投票决定 Arbitrum 生态系统的重要决策。
48 | 治理范围包括协议升级、资金分配、生态系统发展等。
49 | 去中心化治理：
50 | $ARB 代币持有者可以通过链上投票表达意见，确保 Arbitrum 生态的去中心化和社区自治。
51 |
52 | ### 2024.12.18
53 | （1）TVL（总锁定价值）
54 | TVL 增长：
55 | Arbitrum 的 TVL 在 DeFi 生态中排名前列，吸引了大量资金流入。
56 | 截至 2023 年，Arbitrum 的 TVL 已达到 数十亿美元。
57 | 主要协议：
58 | Uniswap、Aave、Curve 等主流 DeFi 协议已部署在 Arbitrum 上。
59 | （2）交易量
60 | 交易活跃度：
61 | Arbitrum 的交易量持续增长，用户活跃度高。
62 | DEX 交易量：
63 | 以 Uniswap 为代表的 DEX 在 Arbitrum 上的交易量显著增加。
64 | （3）用户增长
65 | 用户数量：
66 | Arbitrum 的用户数量快速增长，吸引了大量 DeFi 用户和开发者。
67 | 社区活跃度：
68 | Arbitrum 的社区活跃度高，Discord、Telegram 等平台用户参与度高。
69 |
70 | ### 2024.12.19
71 | Arbitrum 生态系统概览
72 | （1）DeFi（去中心化金融）
73 | 借贷协议：
74 | Aave、Compound 等借贷协议已部署在 Arbitrum 上，提供低成本的借贷服务。
75 | DEX（去中心化交易所）：
76 | Uniswap、Sushiswap 等 DEX 在 Arbitrum 上提供高效的资产交易服务。
77 | 衍生品：
78 | GMX、dYdX 等衍生品平台在 Arbitrum 上提供杠杆交易和期货交易。
79 | （2）NFT（非同质化代币）
80 | NFT 市场：
81 | OpenSea、Rarible 等 NFT 市场已支持 Arbitrum，推动 NFT 生态发展。
82 | NFT 游戏：
83 | Arbitrum 吸引了多款区块链游戏，提供低成本的游戏体验。
84 | （3）DAO（去中心化自治组织）
85 | Arbitrum DAO：
86 | Arbitrum 是一个去中心化自治组织（DAO），由 $ARB 代币持有者共同治理。
87 | 治理工具：
88 | 提供多种支持 DAO 的工具和平台，帮助社区更好地参与治理。
89 |
90 | ### 2024.12.20
91 | DAO 的历史可以追溯到比特币的诞生，但真正意义上的 DAO 是在以太坊平台上实现的。The DAO 是第一个真正意义上的 DAO，虽然遭遇了失败，但推动了 DAO 的发展。随着区块链技术的成熟和智能合约安全性的提升，越来越多的 DAO 项目涌现，推动了去中心化治理的发展。DAO 的未来发展将依赖于技术进步、治理模式和应用场景的进步。
92 |
93 | ### 2024.12.23
94 | ARB 的未来发展将取决于 Arbitrum 技术的发展、生态系统的建设、市场和用户的接受度、监管环境以及代币经济模型等多个因素。虽然无法准确预测 ARB 的具体走势，但如果 Arbitrum 能够持续创新并吸引更多的用户和开发者，ARB 有望在加密货币市场中占据一席之地。然而，投资者在做出投资决策时应谨慎，考虑各种风险因素。
95 |
96 | ### 2024.12.25
97 | Arbitrum（ARB）作为区块链领域的 Layer 2 扩展解决方案，存在以下一些缺点：
98 | 经济与市场方面
99 | 代币价格波动与持有者亏损：ARB 代币价格表现疲软，自 2024 年 1 月创下历史新高后一路下跌，截至 2024 年 7 月，97% 的 ARB 持有者处于亏损状态，仅有 3% 的持有者在当前价格持平，几乎没有持有者盈利。
100 | 解锁压力与抛压风险：2024 年 3 月开始 Arbitrum 团队和投资者开始解锁大量 ARB 代币，且后续每月仍有大量代币解锁，总价值巨大，这无疑会给市场带来巨大的抛压，若市场流动性持续走低，将带动其代币价格进一步下探。
101 | 生态补贴模式问题：Arbitrum 通过大撒币模式补贴生态发展，如资助游戏开发、为项目提供赠款等，但这种方式不仅未能给代币赋能，还增加了抛压，引发社区不满，被指是典型的 “低流通、高排放” 的生态补贴打法，导致 “市值不断增长、代币趋势波动”。
102 |
103 | ### 2024.12.27
104 | 你好
105 |
106 |
--------------------------------------------------------------------------------
/missingtheway.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # Tomas
55 |
56 | 1. Hi，大家好，我是一个社区新人，之前一直在关注共学这一种形式，这次鼓起勇气参与这次社区共学活动，希望可以通过学习提升自己。
57 | 2. 你认为你会完成本次残酷学习吗？我已经做好完成的准备。
58 |
59 | ## Notes
60 |
61 |
62 |
63 | ### 2024.12.10
64 | # Arbitrum
65 |
66 | > Arbitrum网络是Ethereum网络的扩展网络，它设计出来的目的就是为了扩展Ethereum并解决Ethereum网络中的一些问题。在Arbitrum网络中你可以做一切你可以在Ethereum网络中做的事情，使用web3App，部署智能合约。但是，使用Arbitrum 你的交易的手续费会更低，你交易所花费的时间会更少。其依靠的核心的核心机制是Optimistic Rollup protocols（乐观假设）其将大部分交易移到链下执行，降低交易成本提高吞吐量。同时其安全性依靠Ethereum主网，保证了安全性。
67 | >
68 |
69 | **The Arbitrum Rollup mechanism adopts an “innocent until proven guilty” attitude.**
70 |
71 | ***Arbitrum的核心机制为 Arbitrum Rollup***
72 |
73 | # Some introduction about Arbitrum
74 |
75 | > [https://docs.arbitrum.io/welcome/arbitrum-gentle-introduction](https://docs.arbitrum.io/welcome/arbitrum-gentle-introduction)
76 | >
77 |
78 | ## Why do we need Arbitrum?
79 |
80 | 因为以太坊的TPS（transactions per second）太低，大概只有20到40，达到上限后用户进行竞争导致交易fee上涨，而设计导致其瓶颈已经很难提升。
81 |
82 | ## Why does Ethereum have a low TPS?
83 |
84 | 因为以太坊就是设计决定，必须要在所有节点上同步交易，并确保其可行性（分布式账本），其势必会影响j交易的并发性和交易速度。
85 |
86 | ## How does Arbitrum solve the problem?
87 |
88 | Arbitrum 通过引入Layer 2 网络和 Arbitrum RollUp 来解决这个问题，Arbitrum Rollup 是作为Ethereum 子模块运行的，与传统意义上的L1交易不同，我们不需要在Ethereum节点上处理每一笔Arbitrum交易，相反，Ethereum采用了一种：**“innocent until proven guilty” 在证明其有罪前其即是无罪的理论。当违规操作出现时，争议处可以被反驳，如果反驳成功无效的交易被忽视，欺诈者会被采取经济惩罚；**
89 |
90 | 这种引入链下的操作极大的增加了TPS，提高交易速度，减少交易过程中产生的 gas fee。
91 |
92 | ## Who does this work to prove fraud?
93 |
94 | > 把Arbitrum chain状态推向L1，并且对其他有可能不正确的声明提出质疑的叫做 **vaildator**
95 | >
96 |
97 | **vaildator** 并没有权限限制，只要可以运行节点，并且愿意质押一定数量的Ether，都可以成为 **vaildator 。此外只要有一个诚实的节点那么就可以确保这条链是安全的。因为一个vaildator可以抓到任意数量的欺诈者，这也大大增强了其中的安全性。**
98 |
99 | # How exactly is Fraud Proven? (欺诈行为是如何被证明的)
100 |
101 | 当两个validator 产生了不同的判断，最多只有一个 validator 是诚实的。在冲突发生的情况下，他们会进行一个交互游戏 **ChallengeManager** 这个游戏会逐渐缩小冲突范围，直到缩小到一个简单的计算，例如两数相加。这是在L1中进行的，并且会证明其中有一方说的是真话。
102 |
103 | ### 2024.12.11
104 |
105 | 今天按照https://docs.arbitrum.io/build-decentralized-apps/quickstart-solidity-hardhat 上的方法搭建了，Dapp并使用本地节点进行了部署。
106 |
107 | # RollUp的作用
108 |
109 | Roll up 译为压缩整理，Roll up 的作用就是将区块链上需要计算的内容Copy到以太坊之外的Layer2协议进行计算。然后再将结果结果信息打包发送到链上网络。
110 | ZK RollUp 引入了零知识证明，通过复杂严谨的逻辑验证方法进行验证。来认证不同数据的真实性，验证完成后将存有大量签名的数据存入区块链网络。
111 |
112 | ### 2024.12.12
113 |
114 | RollUp将大量的计算放到了L2进行，而L2一般是在一个单台服务器上也叫做 Sequencer（排序器）的地方运行的。Sequencer 在感官上接近于中心化服务器，在RollUp中进行大量运算后，Sequencer会把交易后的状态推给 L1 链，这节省了很多在L1链上处理交易的时间，也降低了gasFee。
115 |
116 | RollUp 扩容可以概括为两点：
117 |
118 | **成本优化：**其运行在单台服务器上，效率得到了大大提高，降低了交易成本。
119 |
120 | **安全保障：**其将交易过程及交易完成后的状态都同步到了L1链，其可以通过只能合约来校验状态的有效性。同时以太坊中还会保存L2中的历史记录，即使 Sequencer 宕机也可以还原出完整的交易记录。
121 | ### 2024.12.13
122 | 今天阅读了《前Arbitrum技术大使解读Arbitrum的组件结构》的两篇文章，让我对RollUp的ChallengeManager机制，和OP RollUp有了更深层次的理解，今天由于时间问题先暂时不写总结了，明天阅读原生文档后再行补充。
123 | ### 2024.12.14
124 | Arbitrum One是典型的OPR，它部署在L1上的合约，并不主动验证提交过来的数据，乐观地认为这些数据没有问题。如果提交的数据有错误，L2的验证者节点会主动发起挑战。
125 | 因此OPR也暗含一条信任假设：任意时刻⾄少有⼀个诚实的L2验证者节点。⽽ZKR的合约则通过密码学计算，主动但低成本地验证排序器提交的数据。
126 | ## 排序器Sequencer：
127 | 接收用户交易并进行排序，计算交易结果，并迅速（通常<1s）返还给用户回执。用户往往在几秒内就能看到自己的交易在L2上链，体验就如同Web2平台。
128 | 同时，排序器还会在以太坊链下即时广播最新产生的L2 Block，任何一个Layer2节点都可以异步的接收。但此时，这些L2 Block不具备最终确定性，可以被排序器回滚掉。
129 | 每隔几分钟，排序器会将排序后的L2交易数据进行压缩，聚合成批次（Batch），提交至Layer1上的收件箱合约SequencerInbox，以保证数据可用性和Rollup协议的运转。一般而言，被提交至Layer1上的L2数据无法回滚，可以具备最终确定性。
130 | ## Arbitrum Rollup协议：
131 | 定义Rollup链的区块 RBlock 的结构，链的延续方式，RBlock的发布，以及挑战模式流程等⼀系列的合约。注意，这⾥说的Rollup链并不是大家理解的Layer2账本，而是Arbitrum One为了施展欺诈证明机制，而独立设置的一条抽象出来的“链状数据结构”。
132 | ⼀个RBlock可以包含多个L2区块的结果，⽽且数据也迥异，它的数据实体 RBlock 存储在RollupCore的⼀系列合约中。如果⼀个 RBlock 存在问题，Validator将⾯向该RBlock的提交者对其进⾏挑战。
133 | ### 2024.12.16
134 | ## ChallengeManager
135 | 假如验证者A提出Rollup Block到L1上，而B不同意，对其进行挑战。
136 | 在B发起挑战后，ChallengeManager合约负责验证对挑战步骤的细分过程：
137 | 1.细分是一个双方轮流互动的过程，一方对某个Rollup Block中包含的历史数据进行分段，另一方指出是哪部分数据片段有问题。类似于二分法（实际是N/K）不断渐进缩小范围的一个过程。
138 | 2.之后，可以继续定位至哪条交易及结果有问题，再进一步细分至该交易中有争议的某条机器指令。
139 | 3.ChallengeManager合约只检查对原始数据进行细分后，产生的『数据片段』是否有效。
140 | 4.当挑战者和被挑战者定位到了将被挑战的那条机器指令后，挑战者调用oneStepProveExecution()，发送单步欺诈证明，证明这条机器指令的执行结果有问题。
141 | 单步证明最终证明的是WAVM指令集中的单步指令，当合约拿到对应的单步指令后，会与RollUp Block中的指令进行对比，如果不同则挑战成功，如果相同则挑战失败。
142 | ### 2024.12.17
143 | ## Any Trust Chain
144 | 使用Any Trust Chain 可以显著的降低交易的手续费，其与Roll up 网络不同，它并没有采用和Roll up 一样的去中心化/无需信任/无需认证的安全措施，与Roll up 不同，它并没有把全部数据打包上传到L1网络上，它是一种链下的处理方案。当遇到问题时，其会转换为Roll up 模式，使用Any Trust Chain 时必须要有两个验证者保持为诚实的。对于那些需要非常高的交易吞吐量和并不需要严格去中心化的应用，Any Trust Chain 将是一个非常好的选择。
145 | 在Arbitrum网络中，Arbitrum One 为 Roll up 网络，Arbitrum Nova 为 Any Trust Chain 网络。
146 | ### 2024.12.18
147 | **Ethereum 的扩容策略主要分为以下几点：**
148 |
149 | - 分区扩容策略（sharding）：把Blockchain 分片分块，以增加主链上的交易吞吐量和速度，降低费用，但是，由于Roll up 的发明，以及其优秀的能力导致，分片策略并不能成为以太坊扩容的最优解。但是，其仍然对共识机制更简单起到了正面作用。
150 | - Layer 2 ：在主网的基础上引入了二层网络，二层网络多数采用Roll up机制，将二层网络中的数据打包发送到主网，这种将大量的交易处理放到链下的方式大大提升了交易吞吐量，交易速度，降低了GasFee。
151 |
152 | Roll up 的优点：
153 |
154 | - 大大降低了交易的手续费，提高了速度，吞吐量
155 | - 降低了主网的压力
156 | - 继承了与以太坊主网相同级别的安全措施
157 |
158 | Roll up 的缺点：
159 |
160 | - 由于Roll up 的节点可能不是完全去中心化的，其节点可能处在被某些独立组织，第三方组织，或像ETH主网一样的组织中的控制当中，这当然有一定的安全性风险。不过通过validator,sequencer等机制可以保证交易的安全性。
161 |
162 | **Roll up 类型：**
163 |
164 | ZK Rollup , Optimistic Rollup 和 Arbitrum Rollup 的不同之处：
165 |
166 | - ZK Rollup 采用了Zero Knowledge 的方式进行验证，通过对状态进行验证，保证交易的正确性，零知识证明不需要知道具体的交易细节，只需要验证状态正确即为交易诚实。
167 | - Optimistic Rollup 采用了 Fraud Proof 以乐观的态度对待，提交到L1链上的数据，经过7天的验证期后可以完成提款。
168 | - Arbitrum Rollup 同样采用了 Fraud Proof，其与Optimistic Rollup 的核心区别是，Arbitrum Rollup 在争议产生的时候，Arbitrum Rollup 采用多步处理策略也就是 Challenge Manager ，会从区块开始一直分割，知道定位到一条WAVM的指令，与L1链上的 Rollup 进行对比验证。Optimistic Rollup 在产生争议时会进行整个交易的验证，更费时间。
169 | ### 2024.12.20
170 | ## Arbitrum 技术路线图
171 |
172 | > Arbitrum 是由 Offchain Labs 发布的L2链，Offchain Labs 始终坚持一个规则进行技术路线的规划：**Your Chain, Your Rules.** 使用Arbitrum技术允许用户及社区拥有构建自己链的能力，社区拥有自治的权利。
173 | >
174 |
175 | 首先Arbitrum 将会通过Stylus 方式适配使用不同语言来编译WASM ，例如 Rust ，C ，C# ，通过 Stylus 你可以高效执行代码并节省智能合约消耗的Gas费，使用Stylus你的计算资源和内存成本会大大降低。
176 |
177 | ## 去中心化
178 |
179 | Arbitrum 在未来会逐步落实去中心化的实施将去中心化落到实处，比如实现如下功能：
180 |
181 | - ***BoLD* (H2 2024)**
182 | - ***Censorship Timeout* (H2 2024)**
183 | - ***Decentralized Sequencer* (likely 2025)**
184 |
185 | ## 水平扩展
186 |
187 | - ***Fast Withdrawals (Q3 2024)***
188 | - Chain Cluster ***(2025)***
189 |
190 | ## 性能和效率
191 |
192 | - ***Multi-client support* (H1 2025)**
193 | - ***Adaptive Pricing (H1 2025)***
194 |
195 | ## 引入零知识证明
196 |
197 | - ***ZK+Optimistic Hybrid Proving***
198 |
199 |
--------------------------------------------------------------------------------
/nocb.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # Hansen
55 |
56 | 1. 虽然很早就了解过arb，但没有系统的学习和使用过。
57 | 2. 你认为你会完成本次残酷学习吗？ 应该可以完成 ，抽时间学习
58 |
59 | ## Notes
60 |
61 |
62 |
63 | ### 2024.12.10
64 |
65 | #### ARB基础介绍
66 |
67 | - ARB is Optimistic rollup protocol ，is a L2
68 | - L2 是为了Ethereum的扩容
69 | - L1 保证了L2的安全性，
70 | - The only delay that's felt by a user is in "withdrawing" — moving their funds from Arbitrum back to Ethereum;
71 | - 批次，压缩 ，所以L2的费用低和效率高
72 | - 最新技术栈：Stylus ，可以支持 rust
73 |
74 | ### 2024.12.11
75 |
76 | - ARB have 2 chain ，Arbitrum One and Nova. Orbit can create L3
77 | - Arbitrum DAO
78 |
79 | #### Arbitrum suite
80 |
81 | The Arbitrum suite includes the protocols, chains, services, and SDKs that power the Arbitrum ecosystem:
82 |
83 | Arbitrum Rollup: A protocol for scaling Ethereum smart contracts.
84 | Arbitrum AnyTrust A protocol for scaling Ethereum smart contracts even further, with a mild trust assumption.
85 | Arbitrum Nitro The node software that codifies the Rollup and AnyTrust protocols.
86 | Arbitrum nodes Machines that run Nitro in order to service and/or interact with an Arbitrum chain.
87 | Arbitrum One A public Rollup chain.
88 | Arbitrum Nova A public AnyTrust chain.
89 | Arbitrum bridge Lets you move ETH and ERC-20 tokens between Ethereum, Arbitrum, and select Orbit chains.
90 | Arbitrum Orbit Lets you run your own Rollup and AnyTrust chains.
91 | Arbitrum Stylus write contract with rust
92 |
93 | - 用户通过bridge ，dapp 来使用arb
94 | - 开发者可以使用 solidity and rust 语言
95 | - 矿工 运行全节点 nitro
96 | - 通过orbit 可以创建自己的 L3
97 |
98 | #### chain info
99 |
100 | - 介绍了 RPC 的地址 和特点
101 | - 介绍了一些共用的 rpc provider
102 | - 介绍了 几个重要的合约地址 ，及欺诈证明合约 ，bridge ，及水龙头
103 |
104 | ### 2024.12.12
105 |
106 | #### 创建Dapp
107 | - ui -> provider -> node -> contract
108 | - 就像前后端分离一样， ui 是前端， 合约是服务， 用solidity 语言写，部署在去中心化网络。
109 |
110 | ### 2024.12.13
111 | #### run Arbitrum node
112 | - 节点类型： full node， archive node，classic node
113 |
114 | 一般运行full 节点 就可以了 ， 比归档节点要省资源，
115 |
116 | - Nitro ，full node
117 | - hardware： 普通的电脑即可
118 | - 可以用docker
119 | - snapshot 可以快速同步
120 | - 也有rpc 的接口
121 | - 需要和 L1 的接口对接
122 |
123 | - 创建一个本地的为开发用的 虚拟链
124 | - L1 provider
125 | - data stored in blob ，on the beacon chain.
126 |
127 | ### 2024.12.14
128 |
129 | ### 2024.12.15
130 | #### L2技术类型
131 | - Zk Rollups是指一种利用零知识证明的密码学算法，在无需知道验证者是谁的情况下，完成外包工作的Layer2方法。
132 | - Optimistic Rollups是指利用一堆验证者，在默认打包是好的情况下，通过奖惩机制，监督发掘是否有Bug的Layer2方法。
133 | - Optimism和Arbitrum都是Optimisctic Rollups方法为基础开发的项目。
134 | - starknet 是 zk rollup
135 |
136 | #### ARB的逻辑
137 | - Rollup 上，对合约的调用及其 argument（实际参数）都是作为调用数据（calldata）写在链上的，但是合约的实际计算和存储都是在链下完成的
138 | 这个发布上链的断言将所有的调用和结果都 “卷起来”（“rolling up”）成为单笔发送上链的交易。
139 |
140 | - AVM 是L1 和L2 直接的网关，avm读取输入，计算，输出
141 | - Nitro 是 One 的技术栈升级，
142 | - Arbitrum Nova 是基于 AnyTrust 技术搭建的新链，专为游戏、社交应用程序和对成本更敏感的用例而设计-
143 | - Arbitrum Orbit 是一个开发框架，
144 | - Stylus 是 Arbitrum 开发的支持多语言构建应用程序的开源 SDK
145 |
146 | ### 2024.12.16
147 |
148 | #### 深入理解 Arbitrum
149 |
150 | - 交互式欺诈证明 是arb 的重要设计原则。 （但自己并没有看太懂）
151 |
152 | #### Arbitrum 创新的技术路线图
153 | Your Chain, Your Rules
154 | - Stylus
155 | - 允许使用更高效、好用的语言
156 | - 加强去中心化的建设
157 | - Orbit 扩展网络的，
158 | - 多客户端支持
159 | - 自适应定价
160 | - ZK+乐观混合证明：zk可以立即确认断言，
161 |
162 | ### 2024.12.17
163 |
164 | #### Arbitrum生态
165 |
166 | - DEX ：Camelot
167 | - 贷款： Radiant、Aave V3
168 | - 永续合约：GMX
169 | - 期权： Dopex
170 | - 资格认证 - Odyssey
171 | - 游戏： Treasure
172 |
173 | ### 2024.12.18
174 |
175 | #### 上百个生态项目
176 | 总体看上去 arb 的生态已经比较全，
177 |
178 | #### Orbit 生态
179 | one ：是op rollup L2
180 | nova： 基于anytrust 的游戏链
181 | orbit：是L3
182 |
183 | ### 2024.12.19
184 |
185 | #### Constitution of the Arbitrum DAO 章程
186 | 一些章程写在了合约里面，
187 | https://www.tuoluo.cn/article/detail-10106172.html 中文的说明
188 |
189 | #### DAO 治理工具
190 | Tally Snapshot
191 |
192 | #### 章程主要内容框架如下：
193 | - AIP :
194 | - 管理的chains
195 | - DAO 的金库
196 | - Governed Chains：ARB 管理的链
197 | - Non Governed Chains
198 | - 能投票的token
199 |
200 | #### 具体内容
201 | - chain的归属权
202 | - 任何ArbitrumDAO批准的链，都必须与以太坊结算
203 | - 一个AIP 授权一个链
204 | - AIP 的流程
205 | - 1.Temperature Check ，在snapshot 上发布1周
206 | - 2.正式AIP 及呼吁vote ，3天
207 |
208 | ### 2024.12.20
209 |
210 | #### AIP 的流程
211 |
212 | - 第 1 阶段——临时检查（1 周）： 在社区论坛上提出建议，并讨论/辩论 1 周。 提案者可以在 Snopshot 上建立一个投票，以衡量社区对提案的兴趣。
213 | - 第 2 阶段——正式提交 AIP（3 天）： 通过临时检查后，提案者通过 Arbitrum 上的治理合约提交 AIP。 提案者必须拥有一个至少委托 500 万个 $ARB 的地址。
214 | - 第 3 阶段——DAO 对 AIP 进行投票（14-16 天）： Arbitrum DAO 将能够直接在链上对提交的 AIP 进行投票。 如果满足以下条件，则 AIP 将通过： •“赞成”票为多数（阈值 1）； •对于宪法性 AIP，至- 少 5% 的 $ARB 需要投“赞成”票；对于非宪法性 AIP，至少 3%。 如果 API 通过了，则进入第 4-7 阶段；反之，AIP 将进入第 4 阶段，然后进入第 7 阶段。
215 | - 第 4 阶段——L2 等待期（3 天）： 第 3 阶段后，有 3 天的等待期，在此期间，未通过的 AIP 可以提取资金；
216 | - 第 5 阶段——启动并完成 L2→L1 消息（至少 7 天）： 在以太坊上发送 L2-to-L1 消息，表明 AIP 已通过。
217 | - 第 6 阶段——等待期 （3 天）： 确保投票用户有时间在 AIP 生效前取款。
218 | - 第 7 阶段——执行和实施 AIP 平均而言，宪法性 AIP 的流程从临时检查到最终执行大约需要 37 天，而非宪法性 AIP 通常需要 27 天
219 |
220 | ### 2024.12.21
221 |
222 | #### AIP 类型
223 | - 宪法性 AIP 包括：
224 | - 修改 DAO 规则
225 | - 软件更新：安装或修改任何链上的软件；
226 | - 核心：采取任何需要“链所有者”的操作；
227 | - 新链批准：批准一条新链。（治理链和非治理链）
228 | - 非宪法性 AIP 包括：
229 | - 资金：提议如何从 DAO 国库支出或分配资金；
230 | - 信息：向社区提供指导或信息
231 |
232 | #### 委托投票
233 |
234 | 你可以通过将你的投票权委托给其他人来表达你的意见，
235 | - 要委托投票权，你需要一个持有 $ARB 的以太坊钱包
236 | - Tally 上，委托给你信任的人
237 |
238 | #### 安全委员会
239 | 9-12 多重签名钱包的 12 名成员，能够执行 Arbitrum DAO 的投票结果以及紧急行动，负责维护 Arbitrum 链。
240 | 紧急事件， 非紧急事件
241 |
242 | ### 2024.12.22
243 | #### 如何提交一个AIP 协议
244 | - 前提：
245 | - temperature check using snapshot , 50w token
246 | - submit proposal by tally ,1M token
247 | - 类型：宪法型 和 非宪法型
248 | - 结构
249 | - 概要
250 | - 动机
251 | - 根本原因
252 | - 关键条款
253 | - 规范，详单
254 | - 每一步的实现
255 | - 时间线
256 | - 总的费用
257 | - 如果第二次提交，需要有 上一次的link，拒绝原因，变化，附加信息
258 |
259 |
260 | ### 2024.12.23
261 |
262 | #### 治理理念
263 | - Arbitrum DAO 是以太坊区块链上的去中心化自治组织，通过社区驱动治理，
264 | - ARB的持有者可以对组织及技术变化，提议、投票。
265 | - 他基于智能合约的金库系统，安全理事会来管理，（半年一选），Security Council Members ， 12位，公开了其地址
266 |
267 | #### 治理的论坛
268 | https://forum.arbitrum.foundation/
269 |
270 | #### 案例分析
271 | - amelot 是 Arbitrum 上最大的原生 DEX
272 | - 申请资金最多的是 Arbitrum 上 DeFi 类代表项目 GMX
273 |
274 | - 参与者也需要额外满足一系列条件，如：
275 | - 必须明确支出计划和目标，不得将 ARB 转换为其它资产；
276 | - 必须承诺提供有关分配、ARB 支出、交易量、TVL、唯一地址、交易费用等指标；
277 | - 必须完成 Arbitrum 基金会的 KYC；
278 | - 资金只能用于 Arbitrum 网络上的激励等。
279 |
280 | ### 2024.12.24
281 |
282 |
283 | ### 2024.12.25
284 |
285 |
286 | ### 2024.12.26
287 | 昨天忘记 提交了
288 |
289 | #### Arbitrum 开发文档
290 | https://docs.arbitrum.io/welcome/get-started
291 |
292 | https://github.com/dysquard/Arbitrum_Doc_CN 中文文档
293 |
294 | - Arbitrum 门户
295 | https://portal.arbitrum.io/?chains=arbitrum-one
296 |
297 | - 测试链
298 | - https://rinkeby.arbitrum.io/rpc
299 | - ChainID: 421611
300 | - 浏览器 https://rinkeby-explorer.arbitrum.io/#/
301 | - 水龙头： https://faucet.rinkeby.io/
302 |
303 | - 运行 Arbitrum One完整节点
304 | - Docker镜像: offchainlabs/arb-node:v1.3.0-d994f7d
305 | - 数据库应挂载到外部磁盘，以便在重启时能永久保存数据
306 | - Arbitrum 中继： 当运行多个节点时，你希望运行一个 Arbitrum 中继并为所有节点提供回馈
307 |
308 | ### 2024.12.27
309 |
310 | https://github.com/dysquard/Arbitrum_Doc_CN/blob/master/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3%E5%8D%8F%E8%AE%AE/%E6%B4%9E%E6%82%89Arbitrum.md
311 | #### 机制的深入理解
312 | - Arbitrum是一种rollup，这意味着对Arbitrum链的输入也即收件箱中收到的信息，全部都以**calldata**的形式被记录在以太坊上。每个人都能查看收件箱的完整历史，而链状态又完全取决于收件箱历史。因此，仅凭借公开信息就可以决定当前正确的链状态的信息。如有必要，还可重建整个链状态。
313 | - rollup 协议是在L1 上的合约。
314 | - 挑战期（大约为一周）结束后仍没有对rollup区块提出挑战，Arbitrum就会将该rollup区块认定为正确的
315 | - 作恶者的质押资金将被没收，其中一部分将奖励给诚信者
316 | - 如何解决争议？ **交互式证明**：
317 | - 分解争议， 直到找到争议行为
318 | - L1的仲裁合约，对行为进行判定
319 |
320 | 
321 |
322 | #### L2 的架构
323 | - EVM兼容层,ArbOS,AVM,ethBridge, L1
324 | - evm兼容层的合约， 可以加载到 Arbos内，
325 | - AVM 读取输入，计算，再输出， 是L2 和L1 的分界线
326 | - ethBridge 是L1层的合约， AVM的输出结果，会传入这里的rollup合约，写入到L1 ，或执行仲裁合约。
327 |
328 |
329 | ### 2024.12.28
330 |
331 | #### EthBridge 是为了管理Arb的，在L1层的一组合约，包括
332 | 1. 收件箱合约，链的输入
333 | 2. 发件箱合约，链的输出
334 | 3. Rollup 合约：
335 | - rollup协议并不决定交易的结果，它只对结果进行确认
336 | - L2扩容的核心要义就是以太坊不需要承担交易的所有工作量
337 | - 参与rollup协议的人，就是eth的验证者， 需要32个质押。
338 | - 一诚则成： 只要有一个诚实的验证者，那么整个链的正确运行就会有绝对的保证
339 | 4. 挑战合约： 仲裁用的
340 |
341 | ### 2024.12.29
342 |
343 | #### rollup 确认逻辑
344 |
345 | 
346 |
347 | - 区块100已被确认。
348 | - 区块101宣称自己是区块100的正确子区块，但101被拒绝了（因为打了叉）。
349 | - 区块102最终被确认为区块100的正确子区块。
350 | - 区块103也确认了，现在是最新确认区块。
351 | - 区块104是103的子区块，105是104的子区块。由于104是错误的，105自然也会被拒绝，因为它的父区块就是错的。
352 | - 区块106待决。它宣称自己是区块103的子区块，但协议尚未决定是确认还是拒绝它。这是首个待决区块。
353 | - 区块107和108延续自区块106，它们也是待决状态。如果106被拒绝，它们也会被拒绝。
354 | - 区块109不认同区块106，因为它们的父区块相同。它们中至少会有一个被拒绝，但协议尚未解决。
355 | - 区块110跟随109。待决状态。如果109被拒绝，110也会。
356 | - 区块111跟随104。111最终肯定会被拒绝因为其父区块已经被拒绝，但目前111还是待决状态，因为协议是按顺序处理区块的，所以要先处理106到110。在110解决后，111会被立即拒绝。
357 |
358 | ### 2024.12.30
359 |
360 | #### ArbOS
361 | ArbOS是L2上可信赖的『操作系统』，它负责将各个不受信任的合约分隔开，追踪并限制其资源使用，管理着从用户收集资金以给支付验证者的经济模型。当Arbitrum链启动后，ArbOS已经预加载到AVM实例中，准备运行。经过一些初始化工作后，ArbOS启动了其主循环，从收件箱中读取信息，根据信息进行一些工作其中可能会产生一些输出，然后再返回读取下一条信息。
362 |
363 | 原本需要在昂贵的L1上进行的作业都在ArbOS中完成了，享受着L2的速度和低成本且无需信任
364 |
365 | #### Gas
366 | 一笔交易会为四种资源交费：
367 |
368 | - L2 tx：每个L2交易的基础费用，支付交易的服务成本
369 | - L1 calldata：该交易对应的每单位L1 calldata的费用（每个非0字节的calldata都是16单位的，每个0字节的calldata都是4个单位）
370 | - 运算：该交易所使用的每单位ArbGas的费用
371 | - 存储：每单位EVM存储空间的费用，由该交易所增加的净EVM空间计算
372 |
373 | ### 2024.12.31
374 |
375 |
376 |
377 |
378 |
379 |
380 |
381 |
--------------------------------------------------------------------------------
/noyyyy.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | ---
6 |
7 | # Noy
8 |
9 | 1. 自我介绍
10 | Noy, web3 dev
11 | 2. 你认为你会完成本次残酷学习吗？
12 | 信心满满
13 |
14 | ## Notes
15 |
16 |
17 |
18 | ### 2024.12.10
19 |
20 | - Arbitrum作为以太坊的二层扩展解决方案,采用乐观卷叠技术构建。它以低廉的交易费用和快速的处理速度著称,目前在二层网络中占据领先地位,锁定总价值最高。
21 |
22 | - Arbitrum通过作为以太坊的附属系统运行来提高效率。与传统的以太坊一层交易不同,Arbitrum不需要每个以太坊节点都处理所有交易,而是采用"默认无错"的方法。只有在出现争议时才会回到一层网络解决。这种机制使Arbitrum能够高效处理大量交易,同时保持安全性。
23 |
24 | #### 特点
25 |
26 | - 数据公开: 所有用户的交易记录都会直接发布到以太坊主网,确保任何人都可以验证Arbitrum上的活动。
27 | - 验证者机制: 推动Arbitrum链状态更新的参与者被称为验证者。任何人只需运行开源软件并在必要时质押以太币,就可以成为验证者。
28 | - 欺诈证明系统: 当出现争议时,验证者之间会进行一种交互式博弈,以确定哪个验证者是诚实的。最终通过执行一个简单的计算步骤来揭示真相。
29 |
30 | ### 2024.12.10
31 |
32 |
33 |
--------------------------------------------------------------------------------
/onthebigtree.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 |
6 | ---
7 |
8 | # {你的名字}
9 |
10 | 1. 自我介绍
11 | - Yewlne
12 | 2. 你认为你会完成本次残酷学习吗？
13 | - yep
14 |
15 | ## Notes
16 |
17 |
18 |
19 | ### 2024.12.10
20 | # Arbitrum 学习笔记
21 |
22 | ## 什么是 Arbitrum？
23 | - 基于以太坊的 **Layer 2 扩展方案**。
24 | - 核心技术：**Optimistic Rollup**。
25 | - 目标：提高交易速度、降低成本，同时继承以太坊的安全性。
26 |
27 | ---
28 |
29 | ## 为什么用 Arbitrum？
30 | 1. **便宜**：Gas 费用比以太坊便宜得多。
31 | 2. **快**：交易处理速度更快。
32 | 3. **兼容**：支持所有以太坊的 DApps 和智能合约，开发者迁移很方便。
33 | 4. **安全**：最终安全性由以太坊主网保障。
34 |
35 | ---
36 |
37 | ## 技术原理
38 | - **Optimistic Rollup**：
39 | - 把一堆交易数据打包，提交到以太坊。
40 | - 默认假设所有交易都正确，只有争议时才用以太坊验证。
41 | - 节省计算资源，交易更高效。
42 |
43 | ---
44 |
45 | ## 核心生态
46 | - **Arbitrum One**：主链，用于 DeFi 和复杂应用。
47 | - **Arbitrum Nova**：适合游戏和社交类轻量级应用。
48 |
49 | ---
50 |
51 | ## 适合什么场景？
52 | - **DeFi 应用**（比如 Uniswap, Aave）。
53 | - **NFT 铸造与交易**（省费用）。
54 | - **区块链游戏**（交互多，延迟低）。
55 |
56 | ---
57 |
58 | ## 优势总结
59 | - 低成本、高效率。
60 | - 没有牺牲安全性。
61 | - DApps 部署简单，不需要大改代码。
62 |
63 | ---
64 |
65 | ## 如何开始？
66 | 1. 配置钱包（比如 MetaMask），添加 Arbitrum 网络。
67 | 2. 使用桥接工具，把 ETH 转移到 Arbitrum。
68 | 3. 体验 DApps，低费用快交易。
69 |
70 | ---
71 |
72 | ## 其他记住的点
73 | - 开发者友好，几乎不用重新学东西。
74 | - 社区和生态在快速扩展，越来越多项目支持。
75 |
76 | ---
77 |
78 | > 快速总结：Arbitrum = 便宜 + 快 + 兼容 + 安全，适合各种以太坊应用的扩展！
79 |
80 |
81 | ### 2024.07.12
82 |
83 |
84 |
--------------------------------------------------------------------------------
/pillowtalk-Qy.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # {Qy}
55 |
56 | 1. 自我介绍：Qy
57 | 2. 你认为你会完成本次残酷学习吗？：yes
58 |
59 | ## Notes
60 |
61 |
62 |
63 | ### 2024.12.10
64 |
65 | 1.我们可以用以太坊来证明Arbitrum上的欺诈行为吗？但如果发生欺诈行为，我们能绝对确定能够证明这一点吗？
66 | 是的，我们确实可以。这就是“rollup”部分的用武之地。输入 Arbitrum Rollup 链的数据（即用户的交易数据）直接发布在以太坊上。因此，只要以太坊本身安全运行，任何感兴趣的人都可以了解 Arbitrum 中正在发生的事情，并且有能力检测和证明欺诈行为。
67 |
68 | 2.听起来 Arbitrum Rollup 是解决所有扩展问题的理想解决方案？
69 | Arbitrum Rollup 非常棒而且很酷；它的设计主要是为了避免引入任何中心化或信任假设，因此对于以太坊生态系统来说这是一个明显、严格的净赢。然而，去中心化是有代价的，并不是所有应用程序和用户都一定希望或需要付出这个代价。对于具有不同安全考虑的 dapp 用例，Arbitrum 套件中的不同工具都是合适的；即 Arbitrum AnyTrust 链！
70 |
71 | ### 2024.12.10
72 |
73 | ### 2024.12.11
74 |
75 | 1.Arbitrum是一套以太坊扩展解决方案，可以轻松构建和使用去中心化应用程序。本文档提供了 Arbitrum 套件的高级概述以及针对特定受众量身定制的入门指南。
76 |
77 | 2.用户可以通过 Arbitrum 桥或使用已部署到 Arbitrum 链的 dApp 与 Arbitrum 进行交互。
78 |
79 | 3.开发人员通过将智能合约部署到 Arbitrum 链来构建 Arbitrum dApp。
80 |
81 | 4.链运营商使用 Arbitrum Orbit 来运行专用 Rollup 和 AnyTrust 链。
82 |
83 |
84 | ### 2024.12.11
85 |
86 | ### 2024.12.12
87 |
88 | 1.将智能合约部署到 Arbitrum One 主网。现在我们已经验证了我们的智能合约可以在 Arbitrum 的 Sepolia 测试网上运行，我们准备将其部署到 Arbitrum One 主网。这与部署到 Arbitrum 的 Sepolia 测试网的过程相同，只是我们需要以真实的 ETH 美元而不是 ASPL 支付交易费。预计在此步骤中会看到不一致的 $ETH Gas 费 - Gas 和费用部分包含有关如何确定 Arbitrum 交易的 Gas 费的更多信息。
89 |
90 | 2.以太坊是一个去中心化的节点网络，使用以太坊的客户端软件（如 Offchain 的Prysm ）来维护公共区块链数据结构。以太坊区块链数据结构中的数据一次更改一笔交易。智能合约是根据预定义规则执行交易的小程序。以太坊的节点托管并执行智能合约。您可以使用智能合约构建去中心化应用程序 (dApp)，这些应用程序使用以太坊网络来处理交易和存储数据。DApp 允许用户在应用程序之间携带数据和身份，而无需信任中心化服务提供商。运行以太坊验证器节点3的人可以通过代表用户和 dApp 处理和验证交易来赚取 ETH。当网络负载较重时，这些交易可能会很昂贵。
91 |
92 | ### 2024.12.12
93 |
94 | ### 2024.12.13
95 |
96 | 1.ZK Rollups, ZKSnark 或者叫Zero Knowledge Rollups，顾名思义，通过零知识证明验证来进行Rollups环节。 零知识证明，也是区块链公链项目Algorand的创始人Silvio Micali在密码学的主要贡献之一。
97 | 2.Zero Knowledge: 验证者无需看到交易所有数据，Succinct: 言简意赅的，简练的，Non-Interactive: 无需知道验证者是谁，Argument of Knowledge: 证明交易的真实性与正确性。
98 | 3.Optimistic的方法如其名字的意思：乐观的，开始认为所有发送的交易都是值得信赖认证过的。Layer 2验证者需要先质押Token作为保证金，如果验证过程中，别人发现了有问题的打包，那么该验证者（Sequencer）将被罚款部分Token，并把其作为奖励给与发现问题的人。每次数据打包后，会有验证期，以供其他验证者检查是否有问题，是否需要重新退回打包。Optimistic Rollups也具有智能合约功能，可以拥有相应的治理Token。
99 | ### 2024.12.13
100 |
101 | ### 2024.12.14
102 |
103 | 1.Rollup指的是一种整理方法，把一堆交易任务送到Layer2协议去打工，从而提升以太坊的运行效率。
104 | 2.Zk Rollups是指一种利用零知识证明的密码学算法，在无需知道验证者是谁的情况下，完成外包工作的Layer2方法。
105 | 3.Optimistic Rollups是指利用一堆验证者，在默认打包是好的情况下，通过奖惩机制，监督发掘是否有Bug的Layer2方法。
106 | 4.Optimism和Arbitrum都是Optimisctic Rollups方法为基础开发的项目。
107 | 5.Zksync, ZKxxxxxxx很多ZK，都是以ZK Rollups方法为基础或噱头，开发的项目。
108 |
109 | ### 2024.12.14
110 |
111 | ### 2024.12.15
112 |
113 | 1.就以太坊而言，大 gas 容量的 Arbitrum 交易的唯一缺点是它可能需要运行更多的交互步骤（这个也仅仅是在有所争议的情况下）。相反，重执行模式下的 rollup 交易，gas limit 必须小于以太坊的区块 Gas Limit，否则就没法在一笔以太坊交易内模拟执行完这笔交易了（而且模拟执行比起在以太坊中直接执行，gas 消耗量还要更大）。
114 |
115 | 2.合约大小没有限制：交互式证明无需为每一个 L2 合约创建一个以太坊合约，所以也不要求合约符合以太坊合约的限制。对于 Arbitrum 的争议合约来说，在 L2 上部署一个合约的操作也是一系列计算过程的组合，与别的操作没有区别。相反，重执行模式下，L2 合约的大小比以太坊主链上所能容许的还要小，因为要模拟一个合约的执行需要能够仿制（instrument）这个合约，而仿制的代码必须能够放进一个以太坊合约内。
116 |
117 | ### 2024.12.15
118 |
119 | ### 2024.12.16
120 |
121 |
122 |
123 | ### 2024.12.16
124 |
125 | ### 2024.12.17
126 |
127 | Nitro 代表了 Arbitrum 技术发展的最新一步；它是首次在主网 Arbitrum One 链上发布的技术堆栈的升级版，我们现在将其称为“Arbitrum Classic”（并且比2018 年最初的 Arbitrum 白皮书中描述的要高出几步）。在这里，我们将解释 Nitro 升级背后的理由，并概述 Nitro 相对于经典系统的核心优势。从远处看，Classic 和 Nitro 系统做类似的事情：都试图创建一个尽可能接近 EVM 的执行环境，作为以太坊的第二层运行；也就是说，L2 虚拟机状态更新的安全性可以通过以太坊本身的简洁欺诈证明来保证和执行。在 Arbitrum Classic 中，这是通过定制的虚拟机实现的，我们称之为 Arbitrum 虚拟机 (AVM)。Arbitrum 的 L2 状态机的实现（称为“ArbOS”）实际上是一个编译并上传到 AVM 的程序；ArbOS 包括（除其他功能外）模拟 EVM 执行的能力。在 Nitro 中，我们使用 WebAssembly (Wasm)，而不是使用 AVM 执行低级指令。由于 Go 代码可以编译为 Wasm，因此我们可以用 Go 实现 ArbOS 程序，并在其中（作为子模块）包含Geth 本身，这是最广泛使用的以太坊实现。这种架构（可直接使用 Geth 的 EVM 实现）是 Nitro 的定义性特征，也是我们谈论“Nitro”时主要谈论的内容。Nitro 的大部分优势都是这种设计选择的直接或间接结果。我们可以将这些优势总结如下：费用更低、以太坊兼容性更好、简单易用。
128 |
129 | ### 2024.12.17
130 |
131 | ### 2024.12.18
132 |
133 | Stylus 是 Arbitrum 开发的支持多语言构建应用程序的开源 SDK 。这是一种实现 EVM+ 兼容性的产品。简言之，开发人员在 Arbitrum 上既能使用传统 Solidity 语言，又能使用 WASM 兼容的语言，如 Rust、C 和 C++ 等来构建应用程序。此外，Stylus 使 Dapps 的执行更加高效，显著地降低了 gas 成本。Stylus 不局限于支持 Rust、C 和 C++, 例如 Move、Sway、Cairo 和 Go 等。试想下，以后 Aptos/ Fuel/ StarkNet 上的 dApps 能一键迁移至 Arbitrum 上。甚至可以通过 Arbitrum Orbit 实现一键 L3 链的链改。更有趣的是，BOLD、Stylus 都是通用的模块化组件；开发者基于 Arbitrum Orbit 启动特定用例的 L3，可以原生集成 BOLD、Stylus；也可以通过去中心化 DAO 治理的形式，在 L3 启动并平稳运行后再投票决定集成上述模块化组件。
134 |
135 | ### 2024.12.18
136 |
137 | ### 2024.12.19
138 |
139 | 1.Arbitrum Nova 是基于 AnyTrust 技术搭建的新链，专为游戏、社交应用程序和对成本更敏感的用例而设计。Nova 提供了 2 种数据发布方式，一种是像 Nitro 一样以 Calldata 的形式发布完整数据，另一种是发布 DACert 证明数据的可用性。
140 | 2.Arbitrum Orbit 是一个开发框架，允许用户使用任何基于 Arbitrum Rollup 的 L2 网络作为结算层来创建和启动 L3 网络。借助 Arbitrum Orbit，用户可以在隐私、权限、费用代币、治理等方面定制自己的链。Orbit 链为最终用户提供专用吞吐量、流量隔离和 Gas 价格可靠性，从而允许快速迭代特定领域的机制设计和价值捕获机会。
141 | 3.BOLD 是 Arbitrum 团队提出的无需许可验证机制，目的是最小化结算状态的延迟。
142 |
143 | ### 2024.12.19
144 |
145 | ### 2024.12.20
146 |
147 | Arbitrum Nitro 是为所有基于 Arbitrum 的链提供支持的节点软件，并基于Geth构建，Geth 是 L1 以太坊执行规范的 Golang 实现。自Arbitrum Nitro 于 2022 年 8 月 31 日首次亮相以来，许多新的执行层 (EL) 客户端实现已经启动或显着改进 - 所有这些都具有不同且独特的价值主张和优化目标。随着这些替代客户端的稳定性和质量的提高，Offchain Labs 一直致力于准备 Arbitrum 堆栈以支持替代客户端。
148 |
149 | ### 2024.12.20
150 |
151 | ### 2024.12.21
152 | Paradigm 新发布的 Reth 1.0 、 Erigon 3.0和Nethermind ，目标是在 2025 年提供可投入生产的多客户端实施，并简化在网络中添加其他客户端的流程。路。尽管我们当前的分析表明，一些替代客户端在一些性能基准测试中仍然落后于 Geth，但我们认为，随着这些客户端的进一步优化，为 Arbitrum 采用做好准备是明智的做法。
153 | ### 2024.12.21
154 |
155 | ### 2024.12.22
156 | Arbitrum One 于 2022 年 8 月下旬采用了 Arbitrum 的 Nitro 技术堆栈。Nitro 没有依赖定制的 Arbitrum 虚拟机进行低级代码组装，而是使用 WebAssembly (Wasm)。这一变化允许 rollup 直接使用 Go Ethereum 的 EVM 实现，并对应于更低的费用、更好的以太坊兼容性和更大的简单性。
157 | ### 2024.12.22
158 |
159 | ### 2024.12.23
160 |
161 | 1.Mosaic 是 Composable Finance 的跨层资产转移系统，使用流动性管理和即时（JIT）流动性机器人来利用现有的桥接基础设施网络，用作连接多个 EVM 兼容扩展解决方案的桥梁，允许用户在以太坊、Polygon、Arbitrum、Avalanche、Moonriver 和 Fantom 之间无缝转移代币。
162 | 2.Jones DAO：针对期权的收益、策略和流动性协议，主要机枪池（Primary Jones Vaults）产品允许用户将基础资产存入后获得收益率资产代币 jAssets 来代表其存款，在一定的时间窗口后可以通过销毁 jAssets 来提取原基础资产并获得收益，另一方面，Vaults 将寻求尽量规避风险和获得稳定收益，大部分资金将用于通过持有备兑看涨期权来赚取收益，最高 5% 的资金会用于通过购买看涨期权、看跌期权或永续期权进行对冲。Jones Vaults 可能会通过跨平台期权套利来锁定少量无风险收益。
163 |
164 | ### 2024.12.23
165 |
166 | ### 2024.12.24
167 |
168 | Arbitrum DAO是一个基于以太坊区块链的去中心化自治组织 (DAO)。Arbitrum DAO 的核心是一种社区驱动的治理机制，允许$ARB代币持有者对该组织及其管理的技术的变更提出建议并进行投票。
169 | Arbitrum DAO 的治理智能合约在Arbitrum One Rollup 链上实现，这是以太坊区块链的第 2 层扩展解决方案。这些智能合约包括 DAO 的治理代币 $ARB。DAO 成员使用 $ARB 代币对 Arbitrum DAO 提案 ( AIP ) 进行投票。任何给定投票者的投票权重与他们持有（或代表）的 $ARB 数量成正比1。
170 | Arbitrum DAO 拥有内置的财务系统（以智能合约的形式实现）；DAO 的财务用于资助组织及其技术的持续开发和维护。代币持有者可以提议并投票决定如何使用财务资金。
171 | Arbitrum DAO 还内置了一个安全机制，称为“安全委员会”。安全委员会是一组实体，负责确保 DAO 及其链的安全性和完整性。如《宪法》所述，理事会可以绕过缓慢的投票过程，并在发生安全紧急情况时迅速采取行动。安全委员会成员由 DAO 通过半年选举产生。
172 | 总体而言，Arbitrum DAO 是一个强大的工具，可促进 Arbitrum 生态系统的去中心化治理和社区驱动管理。通过持有 $ARB 代币并参与治理过程，个人可以直接影响 Arbitrum 乃至以太坊的未来。
173 |
174 | ### 2024.12.24
175 |
176 | ### 2024.12.25
177 |
178 | 1.Arbitrum 不是唯一的可用于以太坊区块链的第二层解决方案，但是您可能已经猜到，Arbitrum 是最好的。像 Polygon 和 Optimism 这样的解决方案提供了一些好处，但不如 Optimistic Rollup 以及更重要的是可扩展性提升和隐私特性。
179 | 2.在 Arbitrum 基金会的官方网站上，用户可以验证他们已达到的要求和他们被分配到的空投。如果想出售他们的 ARB，用户可以考虑集中式交易所（CEX）以及众多的 DEX。多个 CEX，包括币安，ByBit，OKX，KuCoin 等都已宣布将在介绍日上架 ARB。
180 |
181 | ### 2024.12.25
182 |
183 | ### 2024.12.26
184 |
185 | 为在Arbitrum生态系统中构建应用程序的DAO以及协议协会(以太坊贡献者的集合)分配了单独的分发。在制定这些标准的过程中，我们与Nansen合作，分析了链上数据，以确定每个DAO社区被授予多少令牌。在此过程中，我们考虑了各种定性和定量指标，包括协议何时启动、是本地协议还是多链协议、有多少TVL、活动、交易量、交易价值，以及维护这些指标的一致性。使用多种标准的目的是认识到Arbitrum是具有不同KPI和用户交互的各种项目的所在地。
186 |
187 | ### 2024.12.26
188 |
189 | ### 2024.12.27
190 |
191 | 本章程描述了ArbitrumDAO管理和(或)授权ArbitrumDAO批准的链的决策框架。Dao可以授权创建使用仲裁技术安置到以太坊的附加第2层链，但是每个这样的附加第2层链必须由对应的AIP授权(即，在每个AIP中可以授权不超过一个链)。经如此授权的任何链可受$ARB代币和本章程的管辖，在这种情况下，该链将被视为受管辖链。任何已授权但不受$ARB令牌控制的链都将被视为非受控链。为免生疑问，任何ArbitrumDAO批准的链(无论是受控链还是非受控链)必须在以太坊进行结算。使用ArbitrumDAO批准的链(即，作为“第3层”)的Arbitrum技术的链不需要ArbitrumDAO授权。
192 |
193 | ### 2024.12.27
194 |
195 | ### 2024.12.28
196 |
197 | 紧急行动：
198 | 安理会有权立即执行任何软件升级或采取其他必要行动，以应对可能发生的安全紧急情况（此类行动称为“紧急行动”）。执行任何紧急行动均需获得安理会9/12 的批准。除非发生真正的安全紧急情况，例如可能严重损害 ArbitrumDAO 所管理链的完整性、机密性或可用性的严重漏洞，否则安理会不得使用其权力执行紧急行动。
199 | 在采取任何紧急行动后，安理会必须发布一份全面透明的报告（在安全紧急情况过去后的适当时间），解释所采取的行动以及采取此类紧急行动的合理性。
200 | ArbitrumDAO 能够通过批准和实施宪法 AIP 来限制或消除安全理事会执行紧急行动的权力。
201 |
202 | 非紧急行动：
203 | 安全理事会还可在非紧急情况下批准和实施常规软件升级、常规维护和其他参数调整（此类行动，简称“非紧急行动”），这些行动需要9/12 的批准才能生效。任何非紧急行动经安全理事会批准后，将绕过 AIP 流程的第 1 至 3 阶段，而直接进入 AIP 流程的第 4 至 7 阶段，以便在部署任何非紧急行动之前提供延迟。安全理事会可选择在部署前指定额外的延迟。
204 | ArbitrumDAO 能够通过批准和实施宪法 AIP 来限制或消除安全理事会执行非紧急行动的权力。
205 |
206 | ### 2024.12.28
207 |
208 | ### 2024.12.29
209 |
210 | 1.一系列智能合约负责在Arbitrum One和以太坊之间桥接$ARB。$ARB 代币是 Arbitrum One 的原生代币，这意味着它是在 Arbitrum One 链上的智能合约中铸造的。“反向”网关将全部 $ARB 供应托管在 Arbitrum One 中，并在存款/取款时铸造或销毁第1 层 (L1)代币表示。反向网关通常与标准代币网关进行比较，后者在第 2 层 (L2)上铸造/销毁。
211 | 2.Arbitrum 协议通过一组获得许可的参与方（称为数据可用性委员会 (DAC)）来管理数据可用性。该协议通过引入额外的数据可用性信任假设来代替以太坊的无需信任数据可用性机制，从而降低了交易费用。Arbitrum Nova是 AnyTrust 链的一个示例；Arbitrum One是实现纯粹无需信任（且 L1-gas 密集度更高）的Arbitrum Rollup 协议的替代链。
212 |
213 | ### 2024.12.29
214 |
215 | ### 2024.12.30
216 |
217 | 1.DAO 的成立：Arbitrum DAO（去中心化自治组织）是一个新实体，对 Arbitrum One 和 Arbitrum Nova 链及其底层协议拥有决策权。该 DAO 受Arbitrum DAO 宪法的管辖，该宪法是一套描述 DAO 如何运作的规则。宪法载于 Arbitrum DAO 用于管理自身及其技术的一系列社会契约中。
218 | 2.治理代币发布：治理代币的所有权代表 DAO 内的成员资格。代币持有者可以对 DAO 提案进行投票。Arbitrum 的治理代币是$ARB，并将通过即将到来的空投分发到符合条件的钱包地址。
219 | 3.代码：DAO 治理通常由一系列开源智能合约来促进，这些合约执行特定的决策协议。这些无需信任的智能合约用于逐步取代传统董事会的可信社会合约。Arbitrum DAO 使用智能合约来编纂《Arbitrum DAO 宪法》中阐明的决策协议。
220 |
221 | ### 2024.12.30
222 |
223 | ### 2024.12.31
224 |
225 | ### 2024.12.31
226 |
227 |
228 |
--------------------------------------------------------------------------------
/pliker-git.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 |
6 | ---
7 |
8 | # {Plike}
9 |
10 | 1. 自我介绍
11 | 大理家社区现任主理人，目前在研究线下社区与WEB3.0的结合
12 | 2. 你认为你会完成本次残酷学习吗？
13 | 会，一起加油吧～
14 |
15 | ## Notes
16 |
17 |
18 |
19 | ### 2024.12.10
20 |
21 | 笔记内容
22 | 1.Arbitrum Rollup — 是一种 Optimistic Rollup 协议。
23 | 2.Arbitrum通过Optimistic Rollup技术拓展了L1层，形成了L2层生态。
24 | 3.$ARB治理代币的发行使这些协议各自链以及Arbitrum DAO授权的任何未来链的治理变得去中心化。
25 | 4.$ARB代币可用于对Arbitrum DAO治理提案进行投票，从而让$ARB持有者共同塑造Arbitrum的未来。
26 | 5.代币持有者能够将其投票权委托给代表。
27 | 6.DAO 的成立：Arbitrum DAO（去中心化自治组织）是一个新实体，对 Arbitrum One 和 Arbitrum Nova 链及其底层协议拥有决策权。该 DAO 受 Arbitrum DAO 宪法的核心，该宪法是一套描述DAO 如何兼容的规则。宪法加载于 Arbitrum DAO 用于管理自身技术的一系列社会契约中。
28 | 7.宪法 AIP是指修改宪法或 AIP-1 的文本或程序、在任何链上安装或修改软件、或在任何链上采取任何需要“链所有者”许可的行动。非宪法 AIP是所有其他 AIP，例如那些请求资金/补助金或向社区提供一般指导或信息的 AIP。
29 |
30 | ### 2024.12.10
31 |
32 | ### 2024.12.11
33 | 笔记内容
34 | 1.Arbitrum 的存在是为了“扩大”以太坊
35 | 2.第 1 层最初“乐观地假设”Arbitrum 上的活动遵循正确的规则。如果发生违规行为（即有人声称“现在我拥有了你所有的钱”），则可以在 L1 上对此索赔提出异议；欺诈将被证明，无效索赔将被忽略，恶意方将受到经济处罚。
36 | 3.Arbitrum的交互证明（Interactive Proof） 是其核心技术机制的一部分，用于在以太坊主网上验证计算的正确性。交互证明是通过交互式的挑战-响应过程来验证某个声明的正确性。验证者无需重复整个计算，而是通过一系列对话，与声明者（通常称为挑战者或计算执行者）确认计算结果是否正确。
37 | 4.Optimistic Rollup（如 Arbitrum）依赖交互证明，而 ZK Rollup 使用零知识证明来即时验证计算结果。
38 | 5.Nitro 是 One 的技术栈升级，并不是独立于 One 的网络，Nitro 升级后全称还是 Arbitrum One ；而 Nova 是独立于 One 的网络。
39 | ### 2024.12.11
40 |
41 | ### 2024.12.12
42 | 笔记内容
43 | 1.横向对比，目前 Arbitrum 的社区活跃度还是比较高的，相比而言optimism的活跃度较低
44 | 2.https://forum.arbitrum.foundation/t/opco-a-dao-adjacent-entity-for-strategy-execution/27361/11，最近 Arbitrum 上有一个帖子热度挺高，帖子是关于成立 OpCo 的讨论，从这个帖子可以看出大家对 DAO 的不同面向的思考，对去中心化的坚持和对效率的反思，比较普遍的一个认知是 DAO 因为去中心治理，很容易出现多个项目在干同一件事的情况，资源没有办法进行有效协调，容易各自为营，效率低下，资源匹配低效。但是 OpCo 的建立也没有得到一致的认同，一方面是出于理念和价值和治理的谨慎考虑，OpCo 是否会损害区中心的程度，也有一批人支持 OpCo 的成立，以图解决资料协调和效率问题，但是沿着建立 OpCo 的建立开展的讨论，又面临几方面问题，第一，Arbitrum 生态内部组织协调性问题，目前组织内容已经有 seegov 和基金会两个偏向执行的组织，OpCo 和这两个组织功能上似有重叠，而组织之间的身份定位和工作分配又缺乏上级结构进行协调，这个工作似乎难以开展，另一方面，延展出 OpCo 的职权议题，OpCp 是否应该成为社区的超级 PM ？DAO 生态的项目都经由 OpCo 监督管理，如果按这个路径发展，OpCo 是否权力过大，是否需要这样的一个结构，而相应的，如果不设立类似的职责，这个 OpCo 在生态中的作用又是什么，是否回退成 seedgov 和基金会一样的职能了。
45 | 这一系列讨论，折射出 DAO 生态的复杂性，DAO 在执行和效率上是低效的，高消耗的，以自己的视角观察，DAO 的结构性弊病或许在于——“中心化“的资金池和去中心化的经营模式，资金池是
46 | “公共”的集中的，但是运作是分散的，多元的，这规避了某个单一主体的独裁，但也导致资源的耗散。或许像以太坊生态的局面会更为良性，分裂成无数dapp和组织，EF 也仅作为服务和支持结构，没有绝对权力，一种曼陀式的治理模式。或许比起 DAO 更有生机和生命力的模式还是“生态”，或许“允许”子结构、分形、节点，允许子中心产生的系统才更去中心。
47 | 3.https://forum.arbitrum.foundation/t/non-constitutional-arbitrum-onboarding-v2-a-governance-bootcamp/27546 Arbitrum 上有一个治理训练营的帖子，这个帖子跟 seedao 的治理培训和 lxDAO 目前运作的残酷工学可以做一些呼应。
48 | 4.Arbitrum目前AIP 运作机制是先论坛，再 snapshot、再 tally
49 | ### 2024.12.12
50 |
51 | ### 2024.12.13
52 | 笔记内容
53 | 1.Arbitrum 是第 2 层 (L2) 以太坊扩展解决方案，具有两个通用的 optimistic rolluups。Arbitrum One 是旗舰 rollup，推动了生态系统的大部分采用，而 Arbitrum Nova 是为高吞吐量应用程序构建的较新 rollup。
54 | 2.Offchain Labs 是 Arbitrum 技术的开发公司，负责设计、开发和运营 Arbitrum 网络。Arbitrum 是一个基于以太坊的二层（Layer 2）扩展解决方案，旨在通过 Rollup 技术（特别是 Optimistic Rollup）提高以太坊网络的可扩展性和降低交易成本。
55 | 3.Arbitrum 的治理模式从 Offchain Labs 的主导逐渐过渡到由 ArbitrumDAO 社区管理。这种去中心化治理是 Offchain Labs 的设计目标之一，符合区块链技术的去中心化理念。
56 | 4.ArbitrumDAO 的独立性使得社区能够在必要时限制或拒绝 Offchain Labs 的提案，确保网络的去中心化治理。
57 | 5.在目前的 ArbitrumDAO 结构中，Offchain Labs 并没有直接的替代者，因为它仍然是技术支持和开发的核心力量。然而，DAO 的设计理念是去中心化，理论上允许社区逐步培养新的技术团队，通过提案、投票和资金支持，将 Offchain Labs 的角色分散化甚至替代。
58 | ### 2024.12.13
59 |
60 | ### 2024.12.14
61 | 笔记内容
62 | 1.$ARB 代币是一种 ERC-20治理代币，允许其持有者参与Arbitrum DAO 的链上治理协议。$ARB 代币由位于Arbitrum One （第 2 层Arbitrum 汇总链）上的智能合约铸造。
63 | 2.如果您拥有 $ARB 代币，您可以对影响 Arbitrum One 和 Arbitrum Nova 链的运行和发展的治理提案进行投票。这包括对链进行升级的提案，以及如何使用DAO 国库内的资金的提案。
64 | 3.$ARB 的初始供应量为 100 亿。新的 $ARB 每年最多可以按其供应量的 2% 的速度铸造，第一批铸造将于 2024 年 3 月 15 日生效。$ARB 铸造活动由 DAO 通过宪法提案执行。
65 | 4.Arbitrum（$ARB）的代币分配设计旨在平衡社区、投资者和团队之间的利益。分配给社区的 56% 中，约 42.78%（即 4,278,000,000 枚 $ARB）被分配到 Arbitrum DAO 的国库。
66 | 5.Offchain Labs 团队和投资者合计持有约 44.47% 的 $ARB（即 4,447,000,000 枚）。 然而，这些代币通常有锁仓期和线性解锁计划，以防止短期内过度抛售，具体解锁时间表可参考官方公告。
67 | ### 2024.12.14
68 | ### 2024.12.15
69 | 笔记内容
70 | 1.用户愿意购买 $ARB 的原因在于它承载了治理权的价值预期、生态参与的象征意义，以及市场投机的潜在回报。尽管 $ARB 不代表所有权、没有利润分配权，也不是用于支付交易费用的功能性代币，但它在 Arbitrum DAO 的治理中发挥关键作用，并间接影响 Arbitrum 网络的发展方向。
71 | 2.发行 $ARB 是 Offchain Labs 推动去中心化和生态发展的战略选择，同时避免了股票发行带来的监管风险和约束，为团队和投资者提供了灵活的价值实现方式。
72 | 3.Offchain Labs 团队直接持有 26.94% 的 $ARB，加上早期投资者持有的 17.53%，总共 44.47% 的代币掌握在团队和投资者手中。
73 | 4.即使 DAO 名义上是去中心化治理，团队和投资者仍能通过其代币持有量对治理提案施加重大影响。
74 | 5.团队和投资者合计持有约 44.47% 的 $ARB，治理权在初期可能较为集中。Arbitrum DAO 国库代币的使用由全体持币者共同决定，但如果社区投票率低，治理权可能被大户主导。普通用户持有的 $ARB 占比约为 13.22%，但由于投票分散和参与度不足，实际影响力可能有限。
75 | ### 2024.12.15
76 | ### 2024.12.16
77 | 笔记内容
78 | 1.Arbitrum 基金会还创建了 Arbitrum 安全委员会，这是一组由 12 位“备受尊敬的社区成员”组成的多签，他们将监视链的安全，并在发现弱点时能够迅速采取行动。如果 DAO 确定链不再需要安全委员会，它也可以退休。
79 | 2.$ARB 代币将仅用于协议治理，没有其他用例，目前 Arbitrum 上还是使用 ETH 支付 fee。
80 | 3.机制对比，OPTIMISM 采取两院制，由Token House和Citizens’ House组成，Token House由 OP 代币持有者组成。负责关于协议升级、激励计划分配等事务的投票。Citizens’ House一个公民身份治理系统，旨在通过非代币的方式（如声誉或身份）管理公共资源。专注于社区资金的分配，尤其是公共物品和公益性项目。Citizens’ House 采用“一人一票”机制，避免权力集中，确保每位公民在决策中拥有平等的投票权。拥有否决 Token House 提出的协议升级提案的权力，作为对 Token House 的制衡，防止其被少数利益集团控制。
81 | ### 2024.12.16
82 | ### 2024.12.17
83 | 笔记内容
84 | 1.SARB 代币将使 Arbitrum 生态系统比其他扩展链更加去中心化，成为第一个具有“自我执行治理的 L2 解决方案，这意味着治理完全在链上进行，无需核心团队手动实施提案。
85 | 2.所有 $ARB 代币都存放在治理智能合约中，由 ArbitrumDAO 和/或 Arbitrum 基金会的安全委员会通过链上投票机制直接管理。
86 | 3.DAO的提案和投票机制
87 | 第一阶段：一周的温度检测
88 | 第二阶段：正式的AIP和投票征集
89 | 第三阶段：DAO 在 Arbitrum One 上对 AIP 进行投票（14-16 天）：在此阶段 3 期间，ArbitrumDAO 将能够直接在链上对已提交的 AIP 进行投票。
90 | 第四阶段：L2 等待期（3 或 8 天）： AIP 通过阶段 3 后，DAO 财政相关操作有 3 天等待期，L2 到 L1 消息有 8 天等待期。这让反对 AIP 的用户有时间开始提取资金或在 L2 上采取其他行动。
91 | 第五阶段：阶段 5：发起并最终确定 L2 到 L1 消息（至少 1 个 rollup 协议挑战期）：阶段 4 的等待期过后，将发送一条 L2 到 L1 消息，表明 AIP 已通过。当此消息在 L1 上最终确定后，任何人都可以兑换它以完成此步骤并启动下一步。此步骤可确保在投票期间或投票期后不久发起的任何提款在 L1 上得到确认后，L2 等待期的完成将在 L1 上得到确认。
92 | 第六阶段：阶段 6：L1 等待期（3 天）：阶段 5 完成后，将有额外的 3 天等待期。这确保发起提款或其他 L2 到 L1 消息的用户有时间在 AIP 生效之前在 L1 上执行它们。
93 | 第七阶段：阶段 7：实施： AIP 已全面执行并实施。这可能发生在 L1 上，或通过从 L1 发送到一个或多个受管链的交易进行。
94 | 4.ArbitrumDAO还有安全理事会，
95 | 安全理事会是一个由12 名成员组成的委员会，他们都是多重签名钱包的签名者，有权执行 ArbitrumDAO 和 Arbitrum 基金会授予的某些紧急行动和非紧急行动，并负责维护 ArbitrumDAO 宪法。
96 | ### 2024.12.17
97 | ### 2024.12.18
98 | 笔记内容
99 | 1.Arbitrum DAO 还内置了一个安全机制，称为“安全委员会”。安全委员会是一组实体，负责确保 DAO 及其链的安全性和完整性。根据《宪法》规定，委员会可以绕过缓慢的投票程序，在出现安全紧急情况时迅速采取行动。安全委员会成员由 DAO 通过半年选举产生。
100 | 2.活跃地址数： 截至 2024 年 5 月，Arbitrum 的每日活跃地址数已超过 77.9 万个，位居所有 Layer 2 网络之首。
101 | 3.Offchain Labs 是 Arbitrum 技术的创建者和核心开发者。它负责设计和实现 Arbitrum 的技术架构，包括 Arbitrum One 和 Arbitrum Nova。
102 | 4.Offchain Labs 起初承担了绝大部分责任，但随着 ArbitrumDAO 的成立，网络治理逐步去中心化。
103 | 5.ArbitrumDAO 负责治理和资源分配：通过社区投票决定生态发展的优先事项，确保网络的可持续性和公平性。
104 | ### 2024.12.18
105 | ### 2024.12.20
106 | 笔记内容
107 | 1.一些 DAO 成员可能没有能力积极参与治理过程。这些成员可以将其投票权委托给能够积极参与的其他成员。这种机制称为“投票委托”。
108 | 2.DAO 没有中心化的领导机构，规则和治理机制通过代码和智能合约执行。
109 | 3.现代民主国家治理基于传统法律、政治制度和行政管理系统，依赖中央化的机构（如政府部门、议会、法院等）。民主国家治理通常由行政、立法和司法三权分立的体制组成，通过选举、代表制实现间接民主。
110 | 4.DAO
111 | • 权力分配：
112 | • 去中心化，权力由所有代币持有者共享，权利通常与代币的数量成正比（即持有更多代币拥有更多投票权）。
113 | • 决策基于投票机制，每位参与者可以直接参与决策。
114 | • 治理方式：
115 | • 智能合约自动执行规则，减少人为干预。
116 | • 所有提案需要经过社区投票通过才能执行，强调直接民主。
117 | 5.民主国家
118 | • 权力分配：
119 | • 中央化，权力分布在政府机构之间，人民通过选举将权力委托给代表（议员或总统）。
120 | • 多数国家采用间接民主制度，公民并非直接参与每一项政策的决策。
121 | • 治理方式：
122 | • 决策通过政治协商、立法、行政命令等传统程序推进，通常需要较长时间。
123 | • 强调代议制民主，通过选举选出政治代表，由他们制定和执行政策。
124 | 6.DAO
125 | • 效率：
126 | • 由于智能合约自动化和直接投票，决策效率高。
127 | • 但在规模较大的 DAO 中，治理可能受到低投票率和技术瓶颈的限制。
128 | • 公平性：
129 | • 基于代币的投票权可能导致“资本控制”，持有大量代币的个体或机构拥有更多话语权，影响治理公平性。
130 | 7.民主国家
131 | • 效率：
132 | • 决策和执行通常较慢，受到官僚体制和政治程序的约束。
133 | • 但稳定性高，能够避免过于快速的政策波动。
134 | • 公平性：
135 | • 理论上“每人一票”，强调普选权，但也可能因选区划分、经济不平等等问题影响实际公平性。
136 | ### 2024.12.20
137 | 1.DAO 的治理淡漠（Governance Apathy） 指的是去中心化自治组织（DAO）中成员对治理活动（如提案投票、参与决策）的参与度较低，导致治理效率下降或权力集中于少数活跃成员的现象。这种现象在许多 DAO 项目中都较为普遍，尤其是组织规模较大或治理机制复杂时。
138 | 2.流动民主（Liquid Democracy）
139 | • 流动民主是一种介于直接民主和代议制民主之间的模式，允许成员直接投票或将投票权委托给他人。
140 | • 这种机制特别适合分布式网络中的去中心化治理。
141 | 3.以太坊本身没有明确的“链所有者”概念，但在其约 7 年的生命周期中经历了多次升级，既是为了改进系统（新功能、更好的性能等），也是为了修复关键错误。
142 | 4.像 Arbitrum One 这样的第 2 层 (L2)协议则有着根本的不同，因为它们的规则最终不是由社会共识隐性控制的，而是明确由 L1 智能合约控制的。对于 Arbitrum One 来说，仅仅升级 Arbitrum 节点软件是不够的；它的合约也必须升级，而这些合约不是由 Arbitrum 社区的社会共识控制的，而是由以太坊本身控制的。
143 | 结果是，升级以太坊的共识可以是一个非正式的、链下的过程，而升级 Arbitrum 的共识必须通过由链上合约管理的正式决策过程来运作。换句话说，就是治理。
144 | ### 2024.12.21
145 | 1.DAO 的治理淡漠（Governance Apathy） 指的是去中心化自治组织（DAO）中成员对治理活动（如提案投票、参与决策）的参与度较低，导致治理效率下降或权力集中于少数活跃成员的现象。这种现象在许多 DAO 项目中都较为普遍，尤其是组织规模较大或治理机制复杂时。
146 | 2.流动民主（Liquid Democracy）
147 | • 流动民主是一种介于直接民主和代议制民主之间的模式，允许成员直接投票或将投票权委托给他人。
148 | • 这种机制特别适合分布式网络中的去中心化治理。
149 | 3.以太坊本身没有明确的“链所有者”概念，但在其约 7 年的生命周期中经历了多次升级，既是为了改进系统（新功能、更好的性能等），也是为了修复关键错误。
150 | 4.像 Arbitrum One 这样的第 2 层 (L2)协议则有着根本的不同，因为它们的规则最终不是由社会共识隐性控制的，而是明确由 L1 智能合约控制的。对于 Arbitrum One 来说，仅仅升级 Arbitrum 节点软件是不够的；它的合约也必须升级，而这些合约不是由 Arbitrum 社区的社会共识控制的，而是由以太坊本身控制的。
151 | 结果是，升级以太坊的共识可以是一个非正式的、链下的过程，而升级 Arbitrum 的共识必须通过由链上合约管理的正式决策过程来运作。换句话说，就是治理。
152 | 5.以太坊通过权益证明机制实现共识，通过社会化治理模式协调生态发展。其治理强调开放、透明和协作，结合技术创新与社区共识，形成了全球化的去中心化治理生态。这种模式虽然在效率上存在一定挑战，但通过强大的社区凝聚力和多元化角色参与，确保了以太坊的可持续发展。
153 | ### 2024.12.21
154 |
155 |
--------------------------------------------------------------------------------
/stualan.md:
--------------------------------------------------------------------------------
1 | ### Derick
2 | - 参与学习arb，了解代币经济，架构模型
3 |
4 | ### 2024-12-10
5 |
6 | - arbitrum是以太坊的L2，基于op rollup搭建的，交易成本低，速度快，目前是L2的领头羊，TVL最高
7 | - Arbitrum Rollup 通过将其作为以太坊的子模块运行来解决这一问题。与常规的 L1 以太坊交易不同，Arbitrum 不要求以太坊节点处理每一笔交易，而是采用“无罪推定”的态度。只有在出现违规时，才会回到 L1 进行争议解决。这种机制使得 Arbitrum 能够高效地处理大量交易，同时保持安全性。
8 | #### 关键特性
9 | - 数据透明性：所有用户的交易数据都会直接发布到以太坊上，确保任何人都能验证 Arbitrum 上的活动。
10 | - 验证者角色：负责推动 Arbitrum 链状态的参与者称为验证者。任何人都可以成为验证者，只需运行开源软件并在必要时质押以太币。
11 | - 欺诈证明：如果发生争议，验证者之间会进行互动游戏，以确定哪个验证者是诚实的，最终通过执行一个简单的计算步骤来证明真相。
12 | ### 2024-12-11
13 | - 学习rollup概念 什么是ZK Rollups
14 | - ZK Rollups, ZKSnark 或者叫Zero Knowledge Rollups，顾名思义，通过零知识证明验证来进行Rollups环节。
15 | - 零知识证明，也是区块链公链项目Algorand的创始人Silvio Micali在密码学的主要贡献之一。
16 | - ZK的四大特点：
17 | 1. Zero Knowledge: 验证者无需看到交易所有数据
18 | 2. Succinct: 言简意赅的，简练的
19 | 3. Non-Interactive: 无需知道验证者是谁
20 | 4. Argument of Knowledge: 证明交易的真实性与正确性
21 |
22 | ZK Rollups与Optimistic Rollups是以太坊的两种主要扩展解决方案，它们在技术实现和机制上存在显著差异。
23 |
24 | ## 基本概念
25 | **ZK Rollups**（零知识卷积）使用零知识证明（如zk-SNARKs）来验证交易的有效性，而不需要透露交易的具体内容。这种方法允许将大量交易压缩成一个单一的证明，提交到主链，从而提高隐私性和效率。
26 |
27 | **Optimistic Rollups**（乐观卷积）则假设所有提交的交易都是有效的，只有在有人提出质疑时才会进行验证。这种机制依赖于防欺诈措施，允许在链外处理交易，减少了对链上计算的需求，但可能会引入延迟，因为存在一个质疑期。
28 |
29 | ## 主要区别
30 |
31 | | 特征 | ZK Rollups | Optimistic Rollups |
32 | |------------------------|------------------------------------------------|------------------------------------------------|
33 | | **验证机制** | 使用零知识证明进行交易验证 | 假设所有交易有效，依赖质疑机制进行验证 |
34 | | **隐私性** | 高，交易细节不被公开 | 较低，交易细节可能被公开 |
35 | | **交易确认时间** | 快速，因可立即验证 | 可能较慢，因为需要等待质疑期 |
36 | | **复杂性** | 需要高级密码学知识和资源来生成证明 | 相对简单，更易于集成 |
37 | | **适用场景** | 适合需要高安全性和隐私性的应用 | 适合对延迟不敏感且希望简化集成的应用 |
38 |
39 | ## 优缺点
40 |
41 | ### ZK Rollups
42 | - **优点**：
43 | - 高隐私性和安全性
44 | - 快速的交易确认
45 | - **缺点**：
46 | - 实现复杂，需要较高的技术门槛
47 |
48 | ### Optimistic Rollups
49 | - **优点**：
50 | - 易于集成，适合现有以太坊应用
51 | - 降低链上计算需求
52 | - **缺点**：
53 | - 可能面临延迟
54 | - 安全性依赖于质疑机制的有效性
55 |
56 |
57 | ### 2024.12.12
58 | ### 什么是欺诈证明（Fraud Proof）？
59 |
60 | **欺诈证明（Fraud Proof）** 是一种用于检测区块链中欺诈行为的机制。在区块链系统中，当某个参与者（比如一个验证者或节点）提交一个无效的区块或交易时，其他节点需要能够证明这个区块或交易的错误，从而维护区块链的完整性和安全性。简单来说，欺诈证明是一个手段，用于证明某个区块的计算结果（或交易状态）是错误的，进而确保网络中恶意行为者无法轻易地伪造交易或篡改状态。
61 |
62 | ### Arbitrum中的欺诈证明
63 |
64 | Arbitrum 是以太坊的二层扩展解决方案（Layer-2），它采用了**Optimistic Rollups**技术。在这种技术中，大部分交易是通过计算链外（off-chain）执行的，然后将执行结果（即区块）提交到以太坊主链。Arbitrum 假设所有提交的交易状态是正确的，只有在出现争议时才会进行验证。这种“乐观”假设使得系统能够更高效地处理交易和状态更新。
65 |
66 | ### 如何在 Arbitrum 中使用欺诈证明？
67 |
68 | 1. **交易执行**：
69 | Arbitrum 基于OP Rollup模型，首先将交易在L2上执行，生成交易状态的变更（包括数据、账本状态等），并将这些变更提交给以太坊主链。这个提交的过程是乐观的，假设提交的结果是正确的。
70 |
71 | 2. **欺诈证明的挑战**：
72 | 任何人（称为挑战者）都可以挑战这些提交的交易。具体来说，当某个验证者认为提交的状态不正确（例如，存在计算错误或恶意操作时），他们可以提出一个**欺诈证明挑战**，请求重新验证某个区块或交易。
73 |
74 | 3. **挑战管理（Challenge Manager）**：
75 | Arbitrum 使用一个名为 **Challenge Manager** 的系统来管理和执行欺诈证明。这个系统使用了一种叫做 **bisection protocol**（二分法协议）的机制来逐步验证交易的正确性。在这个过程中，挑战者和被挑战者轮流提交每一步的计算结果，从而逐渐缩小问题的范围。
76 |
77 | 4. **处理与判定**：
78 | 在挑战的过程中，如果欺诈证明成功（即发现了错误），挑战者可以成功推翻错误的区块，并防止错误的状态被纳入以太坊主链。如果挑战失败，则状态提交被认为是有效的，提交者将继续进行操作。
79 |
80 | 5. **自动化回退机制**：
81 | Arbitrum 中的欺诈证明并不会立即改变状态，而是通过回退机制（比如超时或者一定数量的验证期）来避免系统迅速做出错误的判断。这种回退机制有助于解决恶意参与者提交的无效状态问题。
82 |
83 | ### 欺诈证明的作用
84 |
85 | 1. **增强安全性**：
86 | 欺诈证明提供了一个强大的安全保障机制，确保在OP Rollup模型下，即便有恶意行为者提交无效的状态，系统也能有效地识别并撤销这些错误。通过欺诈证明，Arbitrum 能够保持高效的状态更新，同时保障链上数据的准确性。
87 |
88 | 2. **降低交易成本**：
89 | 因为 Arbitrum 的OP Rollup假设大多数提交的状态是正确的，系统不会立即进行每个交易的完整验证。只有在出现欺诈行为时才会启动额外的验证过程，这大大降低了交易的计算和验证成本。
90 |
91 | 3. **提高吞吐量**：
92 | 通过将大部分计算转移到链外执行，并通过欺诈证明机制只对有争议的部分进行验证，Arbitrum 能够有效提升以太坊网络的吞吐量。与传统的区块链系统不同，Arbitrum 允许通过更少的计算资源处理更多的交易。
93 |
94 | 4. **去中心化与公平**：
95 | 欺诈证明的机制确保了任何人都有机会挑战不正当的区块，这使得系统具有去中心化的特点，并防止单个或少数节点通过提交错误的区块来操纵网络。
96 |
97 | 5. **减少依赖于信任**：
98 | 由于欺诈证明要求所有提交的区块都可以被后期验证，这减少了对单一中心化实体的信任要求。在 Arbitrum 网络中，虽然执行和计算是由少数验证者处理，但任何人都可以在发现错误时对其进行挑战。
99 | ### 2024.12.13
100 | - 请假一天
101 | ### 2024.12.14
102 | - 学习arbitrum中one、nitro、nova版本的介绍
103 | ### Arbitrum One
104 | Arbitrum One是最初推出的版本，采用了Optimistic Rollup技术。它的主要特点包括：
105 | - **数据可用性**：所有交易数据都以Calldata的形式发布到以太坊主网，这样做虽然确保了安全性，但也导致了较高的交易费用。
106 | - **安全性**：与以太坊主网共享安全性，用户可以放心地控制自己的资产。
107 | - **EVM兼容性**：能够运行未修改的以太坊智能合约。
108 | ### Arbitrum Nitro
109 | Arbitrum Nitro是对Arbitrum One的技术栈升级，并不是一个独立的网络。它在2022年8月推出，主要特点包括：
110 | - **性能提升**：通过优化执行过程和数据处理方式，降低了交易费用。
111 | - **更好的兼容性**：Nitro使用WebAssembly（Wasm）作为执行环境，增强了与以太坊的兼容性，使得开发者可以更轻松地迁移合约。
112 | - **交互式欺诈证明**：采用了多轮欺诈证明机制，以提高交易的安全性和效率。
113 | ### Arbitrum Nova
114 | Arbitrum Nova是一个独立于Arbitrum One的网络，于2022年8月上线。其主要特点包括：
115 | - **AnyTrust技术**：Nova使用AnyTrust模型，这意味着它将交易数据存储在链下的数据可用性委员会（DAC）中，而不是直接发布到以太坊主网。这种方式显著降低了交易费用。
116 | - **适合高频交互应用**：Nova特别适合游戏、社交应用等需要高频交互的DApp，因为它在性能上进行了优化，但相对牺牲了一定的安全性。
117 | - **两种数据发布方式**：Nova允许以Calldata形式发布完整数据，或通过DACert证明数据的可用性。
118 | ### 2024.12.15
119 |
120 | #### Nitro的设计理念
121 |
122 | Arbitrum Nitro的设计围绕着几个核心理念，旨在提高性能和兼容性，同时保持安全性。以下是Nitro的四个主要设计理念：
123 |
124 | 1. **排序与确定性执行**：
125 | - Nitro采用两阶段策略处理交易。首先，将交易组织成一个有序序列，然后通过确定性的状态转换函数逐一处理这些交易。这种方法确保了每个交易的结果是可预测的，任何人都可以根据交易序列计算出结果。
126 |
127 | 2. **以Geth为核心**：
128 | - Nitro通过集成流行的以太坊节点软件Geth来支持以太坊的数据结构、格式和虚拟机。这种集成确保了与以太坊的高度兼容性，使得Nitro能够无缝运行未修改的EVM合约。
129 |
130 | 3. **分离执行与证明**：
131 | - Nitro将相同的源代码编译两次，一次用于在Nitro节点中执行，优化速度；另一次用于证明，优化可移植性和安全性。这种分离使得Nitro在执行和证明方面都能达到最佳性能。
132 |
133 | 4. **OP Rollup与交互式欺诈证明**：
134 | - Nitro使用OP Rollup协议将交易结算到以太坊主链，并引入了交互式欺诈证明机制，以提高交易的安全性和可靠性。
135 |
136 | ### 2024.12.16
137 | - ARBITRUM的欺诈证明与op的有些不同，具体来说，op是当有挑战者在窗口期发起验证，会统一走一个流程，一直到窗口期结束判定是否是真的欺诈，而arbi是多轮交互，并且机制是挑战者将押金抵押后，由一个合约作为仲裁院，经过断言后可快速验证欺诈证明
138 | - Arbitrum 采用多轮欺诈证明。简单来说，就是通过二分查找，找到引起分歧的那个区块的第一个操作码。找到之后，只需在链上执行这个操作码。
139 |
140 | > 纠纷 解决协议的结果是一个参与者将被发现是错误的。这个参与者的押金会被罚没。押注会从所在的方框上删除。部分押金会给到纠纷的另一方，剩下的被烧掉。
141 | 当两个质押者押注不同的区块且这两个区块之间没有继承关系时，他们会在某个区块上产生分歧，从而引发挑战。
142 | 挑战主要发生在 Arbitrum 链上，由 L1 合约裁决。
143 | 挑战包括一个在 L2 上进行的交互型多轮切分游戏和一个在 L1 上执行的单步证明。
144 | 如果有质押者对某个区块提出争议，提议该区块的质押者将作为 “被告” 捍卫自己的断言。在切分游戏中，作为 “被告” 的质押者（Alice）为先手，将 N 个指令切分成 K 段，每段的大小是 N/K，且每段都有一个起点和一个终点。
145 | 作为 “原告” 的质押者（Bob）同样将 N 个指令切分成 K 段（每段的大小是 N/K），并将它们与 Alice 的切分段一一对应，发现其中一个切分段的终点与 Alice 的不同。
146 | Bob 实际上是在找出他不认同的切分段。
147 | 接着，Bob 会执行 Alice 最初的操作，将有争议的切分段（大小为 N/K）再切分成 K 个子段，然后将这个切分段连同子段一起发送给 Alice。
148 | Alice 执行 Bob 最初的操作，找到终点不同的那个子段。
149 | 切分流程继续下去，直到 Alice 和 Bob 找到他们产生分歧的那一个指令为止。这个指令被发送给 L1 合约，并由后者执行它，然后决定这场争议的 “胜诉方”。
150 | “败诉方” 将失去质押物，一部分质押物将被销毁（防止攻击者对冲押注），其余则奖励给诚实的 “胜诉方”。
151 | 在整个切分流程中，作为裁决方的 L1 合约不知道任何关于指令的信息，只负责核实双方是否遵循游戏规则。
152 | 在争议期间，其他所有验证者都能在争议敲定之前自行断定争议的结果，这就意味着会发生软分叉，且验证者可以继续在正确的链上提交 Rollup 区块。
153 | 挑战期有一个强制的期限，即，每个质押者大约一周时间。
154 | 每个质押者必须在一周的限期内完成自己的任务，否则就会 “败诉”。
155 | 多个纠纷可以同时解决，但是每个押注者一次最多只能参与一个纠纷。
156 | ### 2024.12.17
157 | - 通过阅读[Your chain,Your rules](https://medium.com/offchainlabs/your-chain-your-rules-offchain-labs-technical-roadmap-to-fuel-arbitrum-innovation-f787f2e85966) 了解他们对于arbi的开发计划，增强开发者体验styuls，增加去中心化排序器，互操作性和可扩展性，零知识证明，增加快速体现功能，允许选定orbit链在更短时间内提现，
158 | - arbitrum nova使用anytrust技术，转为游戏和社交应用设计，可以更快的响应和更好的tps。
159 | ### 2024.12.18
160 | - [Arbitrum TVL](https://defillama.com/chain/Arbitrum) 现在是3.257b
161 | - 跨链桥 (Bridges):
162 | 1. Arbitrum Bridge: 这是官方的跨链桥，用于在以太坊主网和 Arbitrum 之间转移资产。
163 | 2. Hop Protocol: 一个通用的跨链桥协议，支持在多个 Layer-2 网络之间快速转移代币，包括 Arbitrum。
164 | 3. Multichain (原 Anyswap): 一个支持多条链的跨链桥，也支持 Arbitrum。
165 | 4. Synapse Protocol: 另一个多链桥协议，提供跨链资产转移和交换功能。
166 | 5. Celer cBridge: 一个高性能的跨链桥，专注于速度和低成本。
167 | ### 2024.12.19
168 | - $ARB 是一种 ERC-20 治理代币，允许其持有者参与 Arbitrum DAO 的链上治理协议。 $ARB 代币由一个位于 Arbitrum One（一个第 2 层 Arbitrum rollup 链）上的智能合约铸造。 Arbitrum DAO 负责管理宪法中定义的治理协议以及 DAO 治理的技术。
169 | - $ARB 的初始供应量为 100 亿。每年最多可以以其供应量的 2% 的速度铸造新的 $ARB，第一次铸造将于 2024 年 3 月 15 日开始。 $ARB 铸造活动由 DAO 通过宪法提案进行。
170 | - $ARB 代币是一种特殊用途的数字资产，赋予其持有者投票权，以影响 Arbitrum DAO 的运营和发展及其治理的技术。持有 $ARB 代币使您能够与其他价值观一致和激励一致的代币持有者一起民主地塑造 Arbitrum 生态系统的未来。
171 | ### 2024.12.20
172 | - 请假
173 | ### 2024.12.21
174 | - 学习[ARB代币治理](https://docs.arbitrum.foundation/concepts/arb-token)
175 | - $ARB 是一种 ERC-20 治理代币，允许其持有者参与 Arbitrum DAO 的链上治理协议。 $ARB 代币由一个位于 Arbitrum One（一个第 2 层 Arbitrum rollup 链）上的智能合约铸造。 Arbitrum DAO 负责管理宪法中定义的治理协议以及 DAO 治理的技术。$ARB 的初始供应量为 100 亿。
176 | ### 2024.12.22
177 | - 代币基本信息
178 | - 代币类型：$ARB是Arbitrum One链上的ERC-20治理代币。
179 | - 初始供应量：100亿个。
180 | - 通货膨胀率：最高2%每年。
181 | - 铸造/销毁机制：通过L2智能合约进行。
182 | - 空投快照区块：在Arbitrum One链的区块58642080（2023年2月6日）。
183 | - 认领开始时间：在以太坊主网的区块16890400（2023年3月23日）。
184 | - 认领结束时间：在以太坊主网的区块18208000（2023年9月24日），此后$ARB不再可认领。
185 | ##### 代币分配
186 | 根据AIPs 1.1和1.2的通过情况，$ARB的分配如下：
187 | Arbitrum DAO财库：35.28%（35.28亿个）
188 | 团队和贡献者 + 顾问：26.94%（26.94亿个）
189 | 投资者：17.53%（17.53亿个）
190 | 用户（通过空投）：11.62%（11.62亿个）
191 | Arbitrum基金会：7.5%（7.5亿个）
192 | 为构建应用程序的DAOs：1.13%（1.13亿个）
193 |
194 | ### 2024.12.23
195 | - 请假一天
196 | ### 2024.12.24
197 | ##### 用户空投资格
198 | 用户通过一个积分系统来确定可认领的代币数量。主要考虑在Arbitrum One上的活动，同时也包括少量在Arbitrum Nova上的活动。用户在快照日期之前每个合格行为最多获得1点，积分上限为15点。
199 | - 合格行为包括：
200 | 在Arbitrum One上：
201 | 资金桥接到Arbitrum One
202 | 在两个不同月份内进行交易
203 | 1. 在六个月内进行交易
204 | 2. 在九个月内进行交易
205 | 3. 进行超过四次交易或与超过四个不同智能合约互动
206 | 4. 进行超过十次交易或与超过十个不同智能合约互动
207 | 5. 进行超过25次交易或与超过25个不同智能合约互动
208 | 6. 进行超过100次交易或与超过100个不同智能合约互动
209 | 7. 交易总额超过$10,000、$50,000或$250,000
210 | - 在Arbitrum Nova上：
211 | 1. 资金桥接到Arbitrum Nova
212 | 2. 进行三次、五次或十次以上交易
213 | ### 2024.12.25
214 | #### Arbitrum Token Supply 概述
215 |
216 | Arbitrum 是一个以太坊扩展解决方案，旨在提高去中心化应用程序（dApps）的可扩展性和效率。其原生治理代币为 ARB，用户可以通过持有 ARB 代币参与 Arbitrum DAO 的治理投票，共同决定协议和链的未来。
217 |
218 | ### 代币供应情况
219 |
220 | - **总供应量**: ARB 的最大总供应量为 9,999,998,977 个代币。
221 | - **流通供应量**: 当前流通中的 ARB 代币约为 4,097,359,817 个。
222 | - **市场数据**: ARB 的市场资本化约为 4,169,696,073 美元，24 小时交易量约为 1,081,347,794 美元。
223 |
224 | ### 代币分配
225 |
226 | ARB 代币于 2023 年 3 月 23 日启动，初始分配的 12.75% 总供应量分配给合格的接收者。ARB 持有者可以将其投票权委托给其他代表，以参与治理。
227 |
228 | ### 2024.12.26
229 | 
230 | 1. 如果在 Hop 协议奖励计划期间发现空投接收者的钱包地址是女巫地址，则将其列入不合格名单。
231 | 2. 其他反女巫规则如下：
232 | - 如果空投接收者的钱包交易全部发生在前 48 小时内，则将扣除一点。如果空投接收者的钱包余额少于 0.005 ETH 且钱包未与多个智能合约互动，则将扣除一点。
233 | - 在 Arbitrum 基金会的官方网站上，用户可以验证他们已达到的要求和他们被分配到的空投。如果想出售他们的 ARB，用户可以考虑集中式交易所（CEX）以及众多的 DEX。多个 CEX，包括币安，ByBit，OKX，KuCoin 等都已宣布将在介绍日上架 ARB。
234 | ### 2024.12.27
235 | - 请假一天
236 | ### 2024.12.28
237 | Arbitrum DAO的术语表（Glossary）提供了与Arbitrum生态系统相关的关键术语和定义，帮助用户理解其治理结构和操作机制。
238 | ## 主要术语及定义
239 |
240 | 1. **Arbitrum Chain**:
241 | - 基于Arbitrum协议运行的区块链，兼容以太坊虚拟机（EVM），用于结算和简洁的欺诈证明。
242 |
243 | 2. **Arbitrum DAO**:
244 | - 由$ARB代币持有者和代表组成的全球社区，负责治理Arbitrum One和Arbitrum Nova链。
245 |
246 | 3. **治理提案（Governance Proposal）**:
247 | - 用于改变Arbitrum DAO治理协议的提案，包括宪法性提案和非宪法性提案。
248 |
249 | 4. **宪法性提案（Constitutional AIP）**:
250 | - 一种更严格的提案类型，需要更长的延迟才能生效，涉及对章程的修改。
251 |
252 | 5. **非宪法性提案（Non-Constitutional AIP）**:
253 | - 不符合宪法性提案标准的提案，通常处理常规操作或小幅变更。
254 |
255 | 6. **多签钱包（Multisignature Wallet）**:
256 | - 需要多个私钥签署交易的钱包，用于安全委员会触发紧急行动。
257 |
258 | 7. **委托（Delegate）**:
259 | - 有权投票参与治理提案的人，可以是$ARB代币持有者或被其他持有者委托投票的人。
260 |
261 | 8. **数据可用性委员会（Data Availability Committee, DAC）**:
262 | - 负责在Arbitrum AnyTrust协议链中强制执行数据可用性的特定权限方。
263 |
264 | 9. **链所有者（Chain Owner）**:
265 | - 有权升级Arbitrum核心协议合约并设置系统参数的实体，包括Arbitrum DAO和安全委员会。
266 |
267 | 10. **智能合约（Smart Contract）**:
268 | - 存储在以太坊区块链上的自执行代码，自动化任务和协议。
269 |
270 | 11. **节点操作员（Node Operator）**:
271 | - 运行以太坊/Arbitrum生态系统核心协议软件的人，包括以太坊节点和Arbitrum节点。
272 |
273 | 12. **快照投票（Snapshot Poll）**:
274 | - 委托可以进行链外投票的一种机制，用于在治理论坛中进行温度检查。
275 |
276 | ### 2024.12.29
277 | Arbitrum DAO的提案和投票程序是其治理机制的重要组成部分，以下是详细的介绍：
278 | ## 提案流程
279 | 1. **临时检查阶段（1周）**:
280 | - 提案者在社区论坛上提出建议，进行讨论和辩论，持续一周。
281 | - 在此期间，提案者可以在Snapshot上创建投票，以衡量社区对提案的兴趣。
282 |
283 | 2. **正式提交AIP（3天）**:
284 | - 经过临时检查后，提案者需通过Arbitrum的治理合约正式提交AIP（Arbitrum改进提案）。
285 | - 提案者必须拥有至少500万$ARB的代币。
286 |
287 | 3. **DAO投票阶段（14-16天）**:
288 | - Arbitrum DAO成员将在链上对提交的AIP进行投票。
289 | - 提案通过的条件包括：
290 | - 赞成票数超过反对票数。
291 | - 赞成票占投票代币的特定比例：宪法性提案需达到5%，非宪法性提案需达到3%。
292 | ## 投票方式
293 | - **直接投票**: 代币持有者可以直接参与投票。
294 | - **委托投票**: 代币持有者可以将自己的投票权委托给代理人。代理人是被选举出来代表其他代币持有者行使投票权的成员。委托后，持有者可随时撤销委托并收回投票权。
295 |
296 | ## 投票工具
297 | - **Tally平台**: Arbitrum DAO使用Tally作为去中心化治理工具，用户可以通过该平台进行委托和投票操作。
298 |
299 | ### 2024.12.30
300 | Arbitrum 的安全委员会成员页面提供了有关安全委员会结构、成员及其职责的详细信息。
301 | ## Arbitrum 安全委员会概述
302 | ### 1. **安全委员会的角色**
303 | - **职责**: 安全委员会负责确保 Arbitrum 网络的安全性和完整性。它能够在紧急情况下快速采取行动，绕过常规的投票流程，以保护网络免受潜在威胁。
304 | - **组成**: 安全委员会由 9 至 12 名成员组成，这些成员通过多重签名钱包进行管理。
305 | ### 2. **成员选举**
306 | - **选举机制**: 安全委员会的成员由 Arbitrum DAO 定期选举产生，确保委员会的代表性和去中心化。
307 | - **当前成员**: 页面列出了现任安全委员会成员的地址和相关信息，反映了社区对安全管理的重视。
308 | ### 3. **决策流程**
309 | - **紧急决策**: 在发生安全事件时，安全委员会可以迅速做出决策，执行必要的措施以保护网络。
310 | - **投票机制**: 委员会成员需要达到一定数量（如 9 名）才能通过紧急决策，确保决策的有效性和代表性。
311 |
312 | ### 4. **与 DAO 的关系**
313 | - 安全委员会与 Arbitrum DAO 紧密合作，确保治理过程中的安全考虑得到充分体现。DAO 成员可以对安全委员会的操作进行监督，并提出改进建议。
314 |
315 | - Arbitrum 的安全委员会是维护网络安全的重要机构，通过定期选举和多重签名机制确保去中心化与高效决策。其主要职责是在紧急情况下保护网络，并与 Arbitrum DAO 协作以增强治理结构的安全性。
316 |
317 | ### 2024.12.31
318 |
319 |
--------------------------------------------------------------------------------
/sync_status_readme.py:
--------------------------------------------------------------------------------
1 | import os
2 | import subprocess
3 | import re
4 | import requests
5 | from datetime import datetime, timedelta
6 | import pytz
7 | import logging
8 |
9 | # Constants
10 | START_DATE = datetime.fromisoformat(os.environ.get(
11 | 'START_DATE', '2025-01-06T00:00:00+00:00')).replace(tzinfo=pytz.UTC)
12 | END_DATE = datetime.fromisoformat(os.environ.get(
13 | 'END_DATE', '2025-01-26T23:59:59+00:00')).replace(tzinfo=pytz.UTC)
14 | DEFAULT_TIMEZONE = 'Asia/Shanghai'
15 | FILE_SUFFIX = '.md'
16 | README_FILE = 'README.md'
17 | FIELD_NAME = 'Name'
18 | Content_START_MARKER = ""
19 | Content_END_MARKER = ""
20 | TABLE_START_MARKER = ""
21 | TABLE_END_MARKER = ""
22 | GITHUB_REPOSITORY_OWNER = os.environ.get('GITHUB_REPOSITORY_OWNER')
23 | GITHUB_REPOSITORY = os.environ.get('GITHUB_REPOSITORY')
24 | STATS_START_MARKER = ""
25 | STATS_END_MARKER = ""
26 |
27 | # Configure logging
28 | logging.basicConfig(level=logging.INFO,
29 | format='%(asctime)s - %(levelname)s - %(message)s')
30 |
31 |
32 | def print_env():
33 | print(f"""
34 | START_DATE: {START_DATE}
35 | END_DATE: {END_DATE}
36 | DEFAULT_TIMEZONE: {DEFAULT_TIMEZONE}
37 | FILE_SUFFIX: {FILE_SUFFIX}
38 | README_FILE: {README_FILE}
39 | FIELD_NAME: {FIELD_NAME}
40 | Content_START_MARKER: {Content_START_MARKER}
41 | Content_END_MARKER: {Content_END_MARKER}
42 | TABLE_START_MARKER: {TABLE_START_MARKER}
43 | TABLE_END_MARKER: {TABLE_END_MARKER}
44 | """)
45 |
46 |
47 | def print_variables(*args, **kwargs):
48 | def format_value(value):
49 | if isinstance(value, str) and ('\n' in value or '\r' in value):
50 | return f'"""\n{value}\n"""'
51 | return repr(value)
52 |
53 | variables = {}
54 |
55 | # 处理位置参数
56 | for arg in args:
57 | if isinstance(arg, dict):
58 | variables.update(arg)
59 | else:
60 | variables[arg] = eval(arg)
61 |
62 | # 处理关键字参数
63 | variables.update(kwargs)
64 |
65 | # 打印变量
66 | for name, value in variables.items():
67 | print(f"{name}: {format_value(value)}")
68 |
69 |
70 | def get_date_range():
71 | return [START_DATE + timedelta(days=x) for x in range((END_DATE - START_DATE).days + 1)]
72 |
73 |
74 | def get_user_timezone(file_content):
75 | """
76 | Extracts the timezone from the file content, supporting IANA timezone names
77 | (e.g., 'Asia/Shanghai') and UTC offsets (e.g., 'UTC+8').
78 | If no valid timezone is found, defaults to DEFAULT_TIMEZONE.
79 | """
80 | yaml_match = re.search(r'---\s*\ntimezone:\s*(\S+)\s*\n---', file_content)
81 | if yaml_match:
82 | timezone_str = yaml_match.group(1)
83 | try:
84 | # Attempt to interpret as a named timezone (e.g., "Asia/Shanghai")
85 | return pytz.timezone(timezone_str)
86 | except pytz.exceptions.UnknownTimeZoneError:
87 | # If named timezone fails, attempt to interpret as a UTC offset
88 | try:
89 | # Convert UTC offset string to a fixed offset timezone
90 | offset = int(timezone_str[3:]) # Extract the offset value
91 | return pytz.FixedOffset(offset * 60) # Offset in minutes
92 | except ValueError:
93 | logging.warning(
94 | f"Invalid timezone format: {timezone_str}. Using default {DEFAULT_TIMEZONE}.")
95 | return pytz.timezone(DEFAULT_TIMEZONE)
96 | return pytz.timezone(DEFAULT_TIMEZONE)
97 |
98 |
99 | def extract_content_between_markers(file_content):
100 | start_index = file_content.find(Content_START_MARKER)
101 | end_index = file_content.find(Content_END_MARKER)
102 | if start_index == -1 or end_index == -1:
103 | logging.warning("Content_START_MARKER markers not found in the file")
104 | return ""
105 | return file_content[start_index + len(Content_START_MARKER):end_index].strip()
106 |
107 |
108 | def find_date_in_content(content, local_date):
109 | date_patterns = [
110 | r'#\s*' + local_date.strftime("%Y.%m.%d"),
111 | r'##\s*' + local_date.strftime("%Y.%m.%d"),
112 | r'###\s*' + local_date.strftime("%Y.%m.%d"),
113 | r'#\s*' + local_date.strftime("%Y.%m.%d").replace('.0', '.'),
114 | r'##\s*' + local_date.strftime("%Y.%m.%d").replace('.0', '.'),
115 | r'###\s*' + local_date.strftime("%Y.%m.%d").replace('.0', '.'),
116 | r'#\s*' + local_date.strftime("%m.%d").lstrip('0').replace('.0', '.'),
117 | r'##\s*' + local_date.strftime("%m.%d").lstrip('0').replace('.0', '.'),
118 | r'###\s*' +
119 | local_date.strftime("%m.%d").lstrip('0').replace('.0', '.'),
120 | r'#\s*' + local_date.strftime("%Y/%m/%d"),
121 | r'##\s*' + local_date.strftime("%Y/%m/%d"),
122 | r'###\s*' + local_date.strftime("%Y/%m/%d"),
123 | r'#\s*' + local_date.strftime("%m/%d").lstrip('0').replace('/0', '/'),
124 | r'##\s*' + local_date.strftime("%m/%d").lstrip('0').replace('/0', '/'),
125 | r'###\s*' +
126 | local_date.strftime("%m/%d").lstrip('0').replace('/0', '/'),
127 | r'#\s*' + local_date.strftime("%m.%d").zfill(5),
128 | r'##\s*' + local_date.strftime("%m.%d").zfill(5),
129 | r'###\s*' + local_date.strftime("%m.%d").zfill(5)
130 | ]
131 | combined_pattern = '|'.join(date_patterns)
132 | return re.search(combined_pattern, content)
133 |
134 |
135 | def get_content_for_date(content, start_pos):
136 | next_date_pattern = r'###\s*(\d{4}\.)?(\d{1,2}[\.\/]\d{1,2})'
137 | next_date_match = re.search(next_date_pattern, content[start_pos:])
138 | if next_date_match:
139 | return content[start_pos:start_pos + next_date_match.start()]
140 | return content[start_pos:]
141 |
142 |
143 | def check_md_content(file_content, date, user_tz):
144 | try:
145 | content = extract_content_between_markers(file_content)
146 | local_date = date.astimezone(user_tz).replace(
147 | hour=0, minute=0, second=0, microsecond=0)
148 | current_date_match = find_date_in_content(content, local_date)
149 |
150 | if not current_date_match:
151 | logging.info(
152 | f"No match found for date {local_date.strftime('%Y-%m-%d')}")
153 | return False
154 |
155 | date_content = get_content_for_date(content, current_date_match.end())
156 | date_content = re.sub(r'\s', '', date_content)
157 | logging.info(
158 | f"Content length for {local_date.strftime('%Y-%m-%d')}: {len(date_content)}")
159 | return len(date_content) > 10
160 | except Exception as e:
161 | logging.error(f"Error in check_md_content: {str(e)}")
162 | return False
163 |
164 |
165 | def get_user_study_status(nickname):
166 | user_status = {}
167 | file_name = f"{nickname}{FILE_SUFFIX}"
168 | try:
169 | with open(file_name, 'r', encoding='utf-8') as file:
170 | file_content = file.read()
171 | user_tz = get_user_timezone(file_content)
172 | logging.info(
173 | f"File content length for {nickname}: {len(file_content)} user_tz: {user_tz}")
174 | current_date = datetime.now(user_tz).replace(
175 | hour=0, minute=0, second=0, microsecond=0) # - timedelta(days=1)
176 |
177 | for date in get_date_range():
178 | local_date = date.astimezone(user_tz).replace(
179 | hour=0, minute=0, second=0, microsecond=0)
180 |
181 | if date.day == current_date.day:
182 | user_status[date] = "✅" if check_md_content(
183 | file_content, date, pytz.UTC) else " "
184 | elif date > current_date:
185 | user_status[date] = " "
186 | else:
187 | user_status[date] = "✅" if check_md_content(
188 | file_content, date, pytz.UTC) else "⭕️"
189 |
190 | logging.info(f"Successfully processed file for user: {nickname}")
191 | except FileNotFoundError:
192 | logging.error(f"Error: Could not find file {file_name}")
193 | user_status = {date: "⭕️" for date in get_date_range()}
194 | except Exception as e:
195 | logging.error(
196 | f"Unexpected error processing file for {nickname}: {str(e)}")
197 | user_status = {date: "⭕️" for date in get_date_range()}
198 | return user_status
199 |
200 |
201 | def check_weekly_status(user_status, date, user_tz):
202 | try:
203 | local_date = date.astimezone(user_tz).replace(
204 | hour=0, minute=0, second=0, microsecond=0)
205 | week_start = (local_date - timedelta(days=local_date.weekday()))
206 | week_dates = [week_start + timedelta(days=x) for x in range(7)]
207 | current_date = datetime.now(user_tz).replace(
208 | hour=0, minute=0, second=0, microsecond=0)
209 | week_dates = [d for d in week_dates if d.astimezone(pytz.UTC).date() in [
210 | date.date() for date in get_date_range()] and d <= min(local_date, current_date)]
211 |
212 | missing_days = sum(1 for d in week_dates if user_status.get(datetime.combine(
213 | d.astimezone(pytz.UTC).date(), datetime.min.time()).replace(tzinfo=pytz.UTC), "⭕️") == "⭕️")
214 |
215 | if local_date == current_date and missing_days > 2:
216 | return "❌"
217 | elif local_date < current_date and missing_days > 2:
218 | return "❌"
219 | elif local_date > current_date:
220 | return " "
221 | else:
222 | return user_status.get(datetime.combine(date.date(), datetime.min.time()).replace(tzinfo=pytz.UTC), "⭕️")
223 | except Exception as e:
224 | logging.error(f"Error in check_weekly_status: {str(e)}")
225 | return "⭕️"
226 |
227 |
228 | def get_all_user_files():
229 | exclude_prefixes = ('template', 'readme')
230 | return [f[:-len(FILE_SUFFIX)] for f in os.listdir('.')
231 | if f.lower().endswith(FILE_SUFFIX.lower())
232 | and not f.lower().startswith(exclude_prefixes)]
233 |
234 |
235 | def extract_name_from_row(row):
236 | """
237 | Extracts the username from a table row, handling Markdown links.
238 | """
239 | match = re.match(r'\|\s*\[([^\]]+)\]\([^)]+\)\s*\|', row)
240 | if match:
241 | return match.group(1).strip() # Extract the name from the link
242 | else:
243 | # If not a Markdown link, return the content before the first "|"
244 | parts = row.split('|')
245 | if len(parts) > 1:
246 | return parts[1].strip()
247 | return None
248 |
249 |
250 | def update_readme(content):
251 | try:
252 | start_index = content.find(TABLE_START_MARKER)
253 | end_index = content.find(TABLE_END_MARKER)
254 | if start_index == -1 or end_index == -1:
255 | logging.error(
256 | "Error: Couldn't find the table markers in README.md")
257 | return content
258 |
259 | new_table = [
260 | f'{TABLE_START_MARKER}\n',
261 | f'| {FIELD_NAME} | ' +
262 | ' | '.join(date.strftime("%m.%d").lstrip('0')
263 | for date in get_date_range()) + ' |\n',
264 | '| ------------- | ' +
265 | ' | '.join(['----' for _ in get_date_range()]) + ' |\n'
266 | ]
267 |
268 | existing_users = set()
269 | table_rows = content[start_index +
270 | len(TABLE_START_MARKER):end_index].strip().split('\n')[2:]
271 |
272 | for row in table_rows:
273 | user_name = extract_name_from_row(row)
274 | if user_name:
275 | existing_users.add(user_name)
276 | new_table.append(generate_user_row(user_name))
277 | else:
278 | logging.warning(f"Skipping invalid row: {row}")
279 |
280 | new_users = set(get_all_user_files()) - existing_users
281 | for user in new_users:
282 | if user.strip():
283 | new_table.append(generate_user_row(user))
284 | logging.info(f"Added new user: {user}")
285 | else:
286 | logging.warning(f"Skipping empty user: '{user}'")
287 | new_table.append(f'{TABLE_END_MARKER}\n')
288 | return content[:start_index] + ''.join(new_table) + content[end_index + len(TABLE_END_MARKER):]
289 | except Exception as e:
290 | logging.error(f"Error in update_readme: {str(e)}")
291 | return content
292 |
293 |
294 | def generate_user_row(user):
295 | user_status = get_user_study_status(user)
296 | owner, repo = get_repo_info()
297 | if owner and repo:
298 | repo_url = f"https://github.com/{owner}/{repo}/blob/main/{user}{FILE_SUFFIX}"
299 | else:
300 | # Fallback to local if repo info is unavailable
301 | repo_url = f"{user}{FILE_SUFFIX}"
302 | # 修改这里，将用户名替换为markdown链接
303 | user_link = f"[{user}]({repo_url})"
304 | new_row = f"| {user_link} |"
305 | is_eliminated = False
306 | absent_count = 0
307 | current_week = None
308 |
309 | file_name_to_open = f"{user}{FILE_SUFFIX}"
310 |
311 | try:
312 | with open(file_name_to_open, 'r', encoding='utf-8') as file:
313 | file_content = file.read()
314 | except FileNotFoundError as e:
315 | logging.error(f"Error: Could not find file {file_name_to_open}")
316 | # 返回一个包含 "⭕️" 的默认行或者采取其他错误处理措施
317 | return "| " + user_link + " | " + " ⭕️ |" * len(get_date_range()) + "\n"
318 |
319 | user_tz = get_user_timezone(file_content)
320 |
321 | user_current_day = datetime.now(user_tz).replace(
322 | hour=0, minute=0, second=0, microsecond=0)
323 | for date in get_date_range():
324 | # 获取用户时区和当地时间进行比较，如果用户打卡时间大于当地时间，则不显示- timedelta(days=1)
325 | user_datetime = date.astimezone(pytz.UTC).replace(
326 | hour=0, minute=0, second=0, microsecond=0)
327 | if is_eliminated or (user_datetime > user_current_day and user_datetime.day > user_current_day.day):
328 | new_row += " |"
329 | else:
330 | user_date = user_datetime
331 | # 检查是否是新的一周
332 | week = user_date.isocalendar()[1] # 获取ISO日历周数
333 | if week != current_week:
334 | current_week = week
335 | absent_count = 0 # 重置缺勤计数
336 |
337 | status = user_status.get(user_date, "")
338 |
339 | if status == "⭕️":
340 | absent_count += 1
341 | if absent_count > 2:
342 | is_eliminated = True
343 | new_row += " ❌ |"
344 | else:
345 | new_row += " ⭕️ |"
346 | else:
347 | new_row += f" {status} |"
348 |
349 | return new_row + '\n'
350 |
351 |
352 | def get_repo_info():
353 | if 'GITHUB_REPOSITORY' in os.environ:
354 | # 在GitHub Actions环境中
355 | full_repo = os.environ['GITHUB_REPOSITORY']
356 | owner, repo = full_repo.split('/')
357 | else:
358 | # 在本地环境中
359 | try:
360 | remote_url = subprocess.check_output(
361 | ['git', 'config', '--get', 'remote.origin.url']).decode('utf-8').strip()
362 | if remote_url.startswith('https://github.com/'):
363 | owner, repo = remote_url.split('/')[-2:]
364 | elif remote_url.startswith('git@github.com:'):
365 | owner, repo = remote_url.split(':')[-1].split('/')
366 | else:
367 | raise ValueError("Unsupported remote URL format")
368 | repo = re.sub(r'\.git$', '', repo)
369 | except subprocess.CalledProcessError:
370 | logging.error(
371 | "Failed to get repository information from git config")
372 | return None, None
373 | return owner, repo
374 |
375 |
376 | def get_fork_count():
377 | owner, repo = get_repo_info()
378 | if not owner or not repo:
379 | logging.error("Failed to get repository information")
380 | return None
381 |
382 | api_url = f"https://api.github.com/repos/{owner}/{repo}"
383 |
384 | try:
385 | response = requests.get(api_url)
386 | response.raise_for_status()
387 | repo_data = response.json()
388 | return repo_data['forks_count']
389 | except requests.RequestException as e:
390 | logging.error(f"Error fetching fork count: {e}")
391 | return None
392 |
393 |
394 | def calculate_statistics(content):
395 | start_index = content.find(STATS_START_MARKER)
396 | end_index = content.find(STATS_END_MARKER)
397 |
398 | if start_index == -1 or end_index == -1:
399 | logging.error("Error: Couldn't find the stats markers in README.md")
400 | return None
401 |
402 | stats_content = content[start_index +
403 | len(STATS_START_MARKER):end_index].strip()
404 |
405 | # Initialize variables to store statistics
406 | stats = {
407 | "total_participants": 0,
408 | "eliminated_participants": 0,
409 | "completed_participants": 0,
410 | "perfect_attendance_users": [],
411 | "completed_users": [],
412 | "fork_count": 0
413 | }
414 |
415 | # Use regular expressions to extract the data. Handle missing data gracefully.
416 | total_match = re.search(r"- 总参与人数:\s*(\d+)", stats_content)
417 | if total_match:
418 | stats["total_participants"] = int(total_match.group(1))
419 |
420 | completed_match = re.search(r"- 完成人数:\s*(\d+)", stats_content)
421 | if completed_match:
422 | stats["completed_participants"] = int(completed_match.group(1))
423 |
424 | completed_users_match = re.search(r"- 完成用户:\s*([\w\s,]+)", stats_content)
425 | if completed_users_match:
426 | stats["completed_users"] = [x.strip()
427 | for x in completed_users_match.group(1).split(',') if x.strip()]
428 |
429 | perfect_attendance_users_match = re.search(
430 | r"- 全勤用户:\s*([\w\s,]+)", stats_content)
431 | if perfect_attendance_users_match:
432 | stats["perfect_attendance_users"] = [
433 | x.strip() for x in perfect_attendance_users_match.group(1).split(',') if x.strip()]
434 |
435 | eliminated_match = re.search(r"- 淘汰人数:\s*(\d+)", stats_content)
436 | if eliminated_match:
437 | stats["eliminated_participants"] = int(eliminated_match.group(1))
438 |
439 | fork_count_match = re.search(r"- Fork人数:\s*(\d+)", stats_content)
440 | if fork_count_match:
441 | stats["fork_count"] = int(fork_count_match.group(1))
442 |
443 | return stats
444 |
445 |
446 | def update_statistics(content, stats):
447 | start_index = content.find(STATS_START_MARKER)
448 | end_index = content.find(STATS_END_MARKER)
449 |
450 | if start_index == -1 or end_index == -1:
451 | logging.error("Error: Couldn't find the stats markers in README.md")
452 | return content
453 |
454 | stats_text = f"""{STATS_START_MARKER}
455 | ## 统计数据
456 |
457 | - 总参与人数: {stats["total_participants"]}
458 | - 完成人数: {stats["completed_participants"]}
459 | - 完成用户: {', '.join(stats['completed_users'])}
460 | - 全勤用户: {', '.join(stats['perfect_attendance_users'])}
461 | - 淘汰人数: {stats["eliminated_participants"]}
462 | - 淘汰率: {stats["total_participants"] and stats["eliminated_participants"] / stats["total_participants"]:.2%}
463 | - Fork人数: {stats["fork_count"]}
464 | {STATS_END_MARKER}"""
465 |
466 | return content[:start_index] + stats_text + content[end_index + len(STATS_END_MARKER):]
467 |
468 |
469 | def main():
470 | try:
471 | with open(README_FILE, 'r', encoding='utf-8') as file:
472 | content = file.read()
473 | except FileNotFoundError:
474 | logging.error(f"Error: Could not find file {README_FILE}")
475 | return
476 |
477 | content = update_readme(content)
478 | stats = calculate_statistics(content)
479 |
480 | if stats:
481 | content = update_statistics(content, stats)
482 |
483 | with open(README_FILE, 'w', encoding='utf-8') as file:
484 | file.write(content)
485 |
486 | logging.info(f"Successfully updated {README_FILE}")
487 |
488 |
489 | if __name__ == "__main__":
490 | main()
491 |
--------------------------------------------------------------------------------
/wimawang:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Europe/Berlin
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # Wimawang
55 |
56 | 1. 自我介绍: 金融数学背景，人寿业务现金流模型相关工作，完整度过一个伴随比特币出块减半的加密市场周期，参与过链上指数项目及投入。
57 | 2. 你认为你会完成本次残酷学习吗？80%可能性。
58 |
59 | ## Notes
60 |
61 |
62 |
63 | ### 2024.12.10
64 |
65 | - Introduction to Arbitrum
66 |
67 | Arbitrum is a layer-2 solution for Ethereum, enhancing its throughput and reducing costs by processing transactions off-chain and submitting only essential data to the mainnet. The flagship product — Arbitrum Rollup — is an Optimistic rollup protocol that inherits Ethereum-level security.
68 |
69 | - Key Features
70 |
71 | Scalability: Processes a large number of transactions off-chain, significantly reducing the load on Ethereum.
72 |
73 | Lower Costs: Minimizes gas fees by batching transactions and posting them as a single data entry on Ethereum.
74 |
75 | Security: Inherits Ethereum's security model, as all transaction data is anchored to the Ethereum blockchain.
76 |
77 | Compatibility: Fully compatible with the Ethereum Virtual Machine (EVM), making it easy for developers to migrate existing Ethereum dApps to Arbitrum.
78 |
79 | This ability to adjudicate and prove fraud on L1 is Arbitrum’s key, fundamental feature, and is how and why the system inherits Ethereum’s security.
80 |
81 | - Core Components
82 |
83 | Rollups: A technique where multiple transactions are bundled and posted to Ethereum as a single batch.
84 |
85 | Validators: Entities that monitor and validate off-chain transactions to ensure their correctness.
86 |
87 | Fraud Proofs: A mechanism to resolve disputes when a validator submits incorrect data.
88 |
89 | - How Arbitrum Works
90 |
91 | Transaction Submission: Users submit transactions to the Arbitrum chain.
92 |
93 | Processing: Transactions are processed off-chain by validators, reducing computational load.
94 |
95 | Batching: Processed transactions are bundled into rollups.
96 |
97 | Posting to Ethereum: The rollups are periodically posted to the Ethereum blockchain for security and finality.
98 |
99 | - Advantages
100 |
101 | Significantly reduces transaction costs.
102 |
103 | Enhances Ethereum’s scalability without compromising security.
104 |
105 | Fully interoperable with Ethereum, requiring minimal adjustments from developers.
106 |
107 | - Limitations
108 |
109 | Centralization Risk: Initially, a limited number of validators may introduce centralization concerns.
110 |
111 | Dependency on Ethereum: Arbitrum’s security is tied to Ethereum, so any vulnerabilities in Ethereum could affect Arbitrum.
112 |
113 |
114 | Arbitrum represents a significant advancement in Ethereum’s scalability and usability. By leveraging rollups, it provides a high-performance, cost-effective, and secure environment for decentralized applications. Its compatibility with Ethereum ensures that developers can seamlessly adopt it, making it a cornerstone of the Ethereum ecosystem’s scaling strategy.
115 |
116 | ### 2024.12.10
117 |
118 | ### 2024.12.11
119 | Till SDK. https://docs.arbitrum.io/sdk/introduction
120 | ### 2024.12.11
121 |
122 | ### 2024.12.11
123 | Till Stylus. https://docs.arbitrum.io/stylus/stylus-overview
124 | ### 2024.12.11
125 |
126 |
127 |
--------------------------------------------------------------------------------
/wodeche.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # Ache
55 |
56 | 1. LXDAO 治理组成员
57 | 2. 你认为你会完成本次残酷学习吗？ OFC ！
58 |
59 | ## Notes
60 |
61 |
62 | ### 2024.12.09
63 | 111
64 |
65 | ### 2024.12.10
66 |
67 | Arbitrum Rollup 如何扩展以太坊？
68 | Arb 采用“乐观假设”，被证明的欺诈行为将被惩罚
69 | Arb 链上的数据会发布到以太坊主网上，任何人都可以去检测和证明欺诈行为
70 | 每个人都可以成为 Arb 的validator，只要运行开源的验证器软件，并且质押ether
71 |
72 | 欺诈如何被证明？
73 | 由验证者玩一个交互式调用和响应的游戏
74 |
75 | AnyTrust链和 Rollup链
76 | Rollup ：所有数据都发布在L1上
77 | AnyTrust：数据是链下管理，适用于高交易
78 |
79 | ### 2024.12.11
80 | ### 2024.12.12
81 | ### 2024.12.13
82 | ### 2024.12.14
83 | ### 2024.12.15
84 | ### 2024.12.16
85 | ### 2024.12.17
86 | ### 2024.12.18
87 | ### 2024.12.19
88 |
89 |
90 |
--------------------------------------------------------------------------------
/yuhui.md:
--------------------------------------------------------------------------------
1 | ---
2 | timezone: Asia/Shanghai
3 | ---
4 |
5 | > 请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区
6 | > 时区请参考以下列表，请移除 # 以后的内容
7 |
8 | timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
9 |
10 | timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
11 |
12 | timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
13 |
14 | timezone: America/Denver # 山地标准时间 (UTC-7)
15 |
16 | timezone: America/Chicago # 中部标准时间 (UTC-6)
17 |
18 | timezone: America/New_York # 东部标准时间 (UTC-5)
19 |
20 | timezone: America/Halifax # 大西洋标准时间 (UTC-4)
21 |
22 | timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
23 |
24 | timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
25 |
26 | timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
27 |
28 | timezone: Europe/London # 格林威治标准时间 (UTC+0)
29 |
30 | timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
31 |
32 | timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
33 |
34 | timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
35 |
36 | timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
37 |
38 | timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
39 |
40 | timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
41 |
42 | timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
43 |
44 | timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
45 |
46 | timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
47 |
48 | timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
49 |
50 | timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
51 |
52 | ---
53 |
54 | # {yuhui}
55 |
56 | 1. 自我介绍 yuhui
57 | 2. 你认为你会完成本次残酷学习吗？ yes
58 |
59 | ## Notes
60 |
61 |
62 |
63 | ### 2024.12.10
64 |
65 | 笔记内容：Arbitrum是一种基于以太坊的Layer2扩容方案，旨在提升以太坊的可扩展性和交易效率，同时保持去中心化和安全性，在仔细阅读白皮书后我总结出Arbitrum的使命有以下三点：1.提升以太坊网络的扩展性 通过减少主网的交易负载，降低交易费用，提高交易吞吐量 2.保持以太坊的安全性和去中心化 利用以太坊主网作为最终的安全层，确保扩展解决方案不会牺牲以太坊的核心价值。 3.增强用户体验 提供快速、低成本的交易，支持智能合约的无缝迁移，让开发者和用户更容易采用 Arbitrum的特点有以下三点：1.具有高效性 低成本：通过批量处理交易（Rollup），显著降低交易费用。 高吞吐量：相比以太坊主网，Arbitrum可以处理更多的交易，减少拥堵。2.具有兼容性 以太坊兼容性：支持现有的以太坊智能合约和开发工具，开发者可以直接将智能合约迁移到Arbitrum。无需更改代码：支持Solidity和其他以太坊虚拟机（EVM）兼容的语言。Arbitrum的基本原理Arbitrum的工作机制基于一种称为 Optimistic Rollup 的技术。以下是其关键原理：1.批量处理交易在Arbitrum链上，交易被打包处理后，通过Rollup技术将其结果提交到以太坊主网。交易数据会以压缩形式存储在以太坊上，从而减轻主网的存储和处理压力。2.欺诈证明（Fraud Proofs）Arbitrum默认所有提交的数据都是有效的（Optimistic假设）。如果有验证者质疑某笔交易的有效性，可以提交欺诈证明，启动争议解决过程。一旦欺诈行为被确认，相关交易会被回滚，并惩罚恶意验证者。3.链下计算，链上验证大部分交易计算在Arbitrum链下完成，以节省资源和时间。交易结果通过加密证明提交到以太坊主网，确保最终状态的一致性。4.状态通道和侧链结合Arbitrum结合了状态通道和侧链的优点，既提供快速响应，又确保安全性和去中心化。总结而言，Arbitrum通过技术创新和对以太坊生态的深度支持，为解决区块链的三难问题（安全性、去中心化、可扩展性）提供了一个平衡且高效的解决方案。
66 | ### 2024.12.11
67 |
68 | 笔记内容：Rollup 是一种区块链扩展技术，旨在提高公链（如以太坊）的交易吞吐量，同时保持主网的安全性和去中心化特性。其核心理念是将大量交易的计算和存储工作移至链下处理，仅将必要的数据和交易结果提交到主网进行验证和存储，从而大幅降低主网的负担。Rollup 的关键特性在于它将多个交易“打包”（即“roll up”）成一个批量，并通过经济高效的方式与主链交互。
69 |
70 | Rollup 的工作机制可以分为以下几个步骤：首先，用户在链下发送交易，这些交易由 Rollup 网络的节点（称为“Sequencer”或“验证者”）进行收集、排序和执行。节点会将这些交易的计算结果合并为一个单一的状态更新，并生成一个交易批次。随后，Rollup 网络会将交易批次的压缩数据（如交易摘要或状态变化的摘要）提交到主链，这些数据被用作验证链下交易的依据。
71 |
72 | Rollup 的安全性依赖于主链，其链下计算结果会通过特定的机制在主链上进行验证。目前，Rollup 主要分为两种类型：Optimistic Rollup 和 ZK-Rollup。
73 | ### 2024.12.12
74 | 欺诈证明机制的工作原理假设所有交易结果默认有效在 Optimistic Rollup 中，提交到主链的交易批次和状态更新被默认认为是正确的，无需每笔交易都在主链上重新验证。这种“乐观”的假设大幅提高了系统效率。争议窗口期当交易结果提交到主链后，系统会设置一个固定的“争议窗口期”（通常为几分钟到几天不等）。在此期间，任何节点都可以对提交的结果提出质疑，触发欺诈证明过程。提出质疑如果某个节点（称为“挑战者”）认为提交的结果是错误的，可以提交一份质疑声明。此时，系统会启动争议解决流程。欺诈证明流程在欺诈证明流程中，挑战者需要提供链下交易的详细数据，证明提交的交易结果存在错误。系统会通过对比链下交易的执行步骤和主链提交的结果来验证质疑是否成立。
75 | 如果挑战者的质疑成立，提交错误结果的验证者将被认定为恶意行为者，受到惩罚（通常是质押的资金被没收）。
76 | 如果质疑不成立，挑战者的行为被视为恶意挑衅，其质押资金可能会被罚没。
77 | 最终确认状态
78 | 争议窗口期结束后，没有质疑或质疑失败的交易结果会被最终确认，并记录在主链上，成为不可更改的区块链历史。
79 | ### 2024.12.13
80 | 欺诈证明机制的优势1.资源高效 欺诈证明机制减少了主链的计算和存储负担，因为只有在发生质疑时才需要主链参与验证，而大部分交易无需实时验证。2.去中心化与安全性 系统依赖于多个节点的监督，确保任何一方试图提交错误数据都可能被其他节点发现并纠正。主链作为最终的仲裁者，维护了系统的去中心化和安全性。3.经济激励机制 验证者和挑战者都需要质押资金，这种经济激励机制确保参与者有动力提供正确的数据，同时抑制恶意行为。
81 | ### 2024.12.14
82 | 笔记内容：在今天的学习之后我觉得欺诈证明机制有以下挑战1.争议窗口期的延迟因为需要等待争议窗口期结束才能最终确认交易，这可能导致用户体验上的延迟，尤其是在需要即时确认的应用场景中。2.挑战过程的复杂性提交欺诈证明需要链下交易的完整数据，这可能导致较高的存储和计算成本。3.对抗复杂攻击如果恶意行为者反复提交虚假质疑，可能会拖慢交易确认过程，甚至导致网络拥堵。欺诈证明机制是扩展区块链安全性的重要保障，特别是在 Optimistic Rollup 等链下计算方案中。它通过“质疑与验证”的方式，让系统在保持高效的同时确保安全和可靠。这一机制的成功应用，使得区块链能够在扩展性与安全性之间找到平衡，为去中心化应用的大规模普及奠定了基础。
83 | ### 2024.12.15
84 | 笔记内容：交互式欺诈证明是一种用于验证区块链扩展解决方案中的链下交易计算结果是否正确的机制。它的核心目的是在链下和链上的互动中，通过高效的方法定位和验证错误，从而在减少计算和存储开销的同时，保证主链的安全性和去中心化特性。以下是对交互式欺诈证明的详细介绍。在区块链扩展方案（如 Optimistic Rollup）中，交易的计算主要在链下完成，并将最终结果提交到链上。由于主链不会主动验证链下计算的每一步，恶意验证者可能提交错误的交易结果。如果链上直接重演所有计算进行验证，将造成高昂的计算成本，与扩展的初衷相矛盾。交互式欺诈证明通过“分步验证”策略，仅在有争议时验证特定部分的计算，从而显著减少计算成本。这种方法依赖于链下和链上的互动，在两者之间逐步缩小问题范围，最终将争议点精确定位到一个单一的操作步骤。
85 | 交互式证明的思路是让 Alice 和 Bob 参与一个由 L1 合约引导的回合制协议，使用任何 L1 合约所需的最小开销来解决他们之间的分歧。Arbitrum 的方法基于对争议的剖析。如果 Alice 的断言涉及了 N 个执行步骤，那就让她曝光出两个各涉及 N/2 个步骤的断言，然后让 Bob 选择一个来挑战。这样一来，争议的规模就缩小了一半。这个过程持续进行，每一回合都将争议的规模缩小一半，直到争议的范围变成一个执行步骤。注意，直到此时为止，L1 引导合约都不必考虑实际上执行了什么。仅当争议被缩小到单个执行步骤时，L1 引导合约才需要理解这一步要执行什么指令，以及 Alice 对该步的断言是否为真，以此解决争议。交互式证明背后的关键原理是，如果 Alice 和 Bob 有所争议，Alice 和 Bob 应尽可能做链下的工作来解决争议，而不是让 L1 合约承担负担。
86 | ### 2024.12.16
87 | 笔记内容：交互式欺诈证明的挑战与优化：延迟问题：交互式欺诈证明的争议过程需要多轮互动，可能导致交易状态的最终确认存在一定延迟（取决于争议窗口期和交互次数）。恶意质疑挑战者可能滥用系统，频繁提出无效质疑来拖延交易确认。为此，系统设计了质押机制和质疑成本来防止此类行为。数据可用性问题验证和挑战过程中需要访问链下数据。如果恶意验证者拒绝提供完整数据，可能影响验证过程。解决方案包括强制数据可用性规则或设计链下数据的可靠存储方案。交互式欺诈证明广泛应用于 Optimistic Rollup 技术中Arbitrum使用交互式欺诈证明保障其链下交易结果的安全性，通过高效的二分法定位错误。Optimism：同样依赖欺诈证明机制进行链下交易验证，并结合经济激励优化用户体验。交互式欺诈证明是一种高效、安全且去中心化的链下验证机制，通过链下与链上的互动，利用分步验证和二分法策略，在降低计算成本的同时保证交易结果的正确性和系统的安全性。作为 Optimistic Rollup 技术的核心组成部分，它为扩展解决方案提供了强有力的技术支持，有助于推动区块链的大规模应用和生态发展。
88 | ### 2024.12.17
89 | 笔记内容：Arbitrum One：首个主网版本 上线时间在2021年9月 这次升级提供一个功能完整的 Optimistic Rollup 解决方案，帮助以太坊扩展其网络性能，降低交易成本。并采用Optimistic Rollup 技术：Arbitrum One 采用“乐观假设”的方法：默认所有链下执行的交易都是正确的，只有在出现挑战时，才通过欺诈证明机制验证交易。这种设计显著减少了以太坊主网的计算压力。并继承以太坊Arbitrum One 通过将交易数据和欺诈证明机制提交到以太坊，实现了与主链同等的安全性。它还具有EVM 兼容性：Arbitrum One 支持以太坊虚拟机（EVM），开发者可以使用与以太坊相同的工具（如 Solidity 和 Hardhat）部署智能合约，几乎无需修改代码。降低交易费用通过链下批量处理交易并压缩数据，Arbitrum One 的交易费用大大低于以太坊主网，适合大规模应用。
90 | ### 2024.12.18
91 | 笔记内容：Arbitrum Nitro：性能飞跃的升级 通过全新架构提升性能、降低成本，并增强与以太坊的兼容性。
92 | 上线时间：2022年8月31日
93 | 主要改进：1.全新执行环境：WASM + Geth
94 | Nitro 将原有的 Arbitrum 虚拟机（AVM）替换为 WebAssembly（WASM），并在其基础上与 Geth（以太坊客户端） 结合，提供高度优化的 EVM 执行环境。
95 | 结果：Nitro 完全兼容 EVM，开发者可以无缝迁移智能合约到 Arbitrum 网络。
96 | 2.先进的数据压缩
97 | Nitro 对链下交易数据进行高效压缩后提交到以太坊主网，减少了存储和带宽开销。
98 | 结果：进一步降低了用户的交易费用，成本比 Arbitrum Classic 低约 90%。
99 | 3.欺诈证明机制优化
100 | 虽然仍基于交互式欺诈证明，但 Nitro 对欺诈挑战的流程进行了优化，提高了验证效率，减少了链上资源消耗。
101 | 4.大幅提升吞吐量
102 | Nitro 的优化使 Arbitrum 网络的交易处理能力大幅提升，吞吐量达到了以太坊主网的 7-10 倍。
103 | 最终升级结果：交易费用大幅下降，用户体验得到显著改善。性能和吞吐量提高，使 Arbitrum 在 Layer 2 市场中保持领先地位。EVM 兼容性增强，开发者的迁移和部署更加便捷。
104 | ### 2024.12.19
105 | 笔记内容：Arbitrum Nova：为社交与游戏应用优化的链 通过 AnyTrust 技术提供超低成本的链下数据可用性，适合对成本敏感的高频应用场景，如社交、游戏和 NFT。
106 | 上线时间：2022年7月
107 | 主要改进：1.AnyTrust 数据可用性方案
108 | AnyTrust 是 Arbitrum Nova 的核心创新，采用了 信任最小化 的链下数据可用性方案。在 Arbitrum Nova 中，交易数据不需要全部存储在以太坊主网，而是由一组称为 数据可用性委员会（Data Availability Committee, DAC） 的成员负责存储和管 理。只要委员会中有一个诚实节点，数据可用性就能得到保障。
109 | 结果：显著降低了链上数据存储成本，交易费用更低。
110 | 2.适用于高频交易场景
111 | 由于 Nova 大幅降低了交易成本，它特别适合高频、小额的应用场景，例如：Web3 游戏：需要频繁的交易互动，但对成本敏感。社交应用：如链上聊天、互动等。NFT 市场：特别是低价值 NFT 的大规模交易。
112 | 3.安全性与灵活性
113 | Nova 依然继承了以太坊的核心安全性，但通过数据可用性委员会减少了存储成本，提供了性能与安全的平衡。
114 | 最终升级结果：Arbitrum Nova 成功吸引了对成本敏感的高频交易类应用，例如 Reddit 将其社区积分系统（Community Points）部署在 Arbitrum Nova 上。Nova 为 Layer 2 扩展方案引入了新的选择：不同应用可以根据性能和成本需求选择合适的链。
115 | ### 2024.12.20
116 | 笔记内容：扩展性优化：从 Layer 2 到 Layer 3目标：持续提升网络性能，同时保持以太坊的安全性。
117 | 1.Layer 2：Optimistic Rollup 技术1.Arbitrum 以 Optimistic Rollup 为核心，通过链下执行和链上数据存储的方式扩展以太坊网络。2.利用交互式欺诈证明机制确保链下执行的交易正确性。
118 | 2.Layer 3：Arbitrum Orbit
119 | 1.Arbitrum 正在探索和开发 Layer 3 的解决方案，允许开发者在 Arbitrum Layer 2 之上构建自己的定制链。
120 | 2.Layer 3 链的特点是灵活性和可定制性：1.适合特定应用场景（如隐私、企业级应用）。 2.提供更低成本的扩展，同时继承 Layer 2 和以太坊的安全性。
121 | 3.目标场景：1.游戏和社交等高频应用。2.需要独特治理和隐私功能的链。
122 | ### 2024.12.21
123 | Arbitrum技术路线图
124 | 笔记内容：数据可用性创新：AnyTrust 技术
125 | 目标：降低链上数据存储成本，同时确保安全性。
126 | 核心创新：
127 | AnyTrust 技术通过引入 数据可用性委员会（Data Availability Committee, DAC），减少了交易数据直接存储在以太坊主网的需求。
128 | DAC 的角色是管理链下数据，只要委员会中有一个节点诚实，数据就能正常恢复。
129 | 应用场景：
130 | 该技术已经在 Arbitrum Nova 上实现，主要面向对成本敏感的高频交易类应用，如游戏、NFT 市场和社交应用。
131 | 优点：
132 | 显著降低交易费用。
133 | 提供高效、安全的数据存储方案。
134 | ### 2024.12.22
135 | 笔记内容：Arbitrum 的技术路线图总结
136 | Arbitrum 的技术路线图通过持续优化扩展性、数据可用性、开发者体验和去中心化治理，确保其在 Layer 2 生态中保持领先地位。其核心创新包括：
137 | 1.Layer 2 和 Layer 3 的协同发展。
138 | 2.AnyTrust 技术 带来的低成本数据存储方案。
139 | 3.Arbitrum Stylus 的多语言支持和高性能执行。
140 | 4.DAO 驱动的治理，促进去中心化和社区参与。
141 | 5.模块化 Rollup 和隐私解决方案，为未来区块链生态的多样化需求提供支持。
142 | 这些创新确保了 Arbitrum 不仅满足当前区块链生态的扩展需求，还为未来 Web3 应用的广泛发展提供了坚实的基础。
143 | ### 2024.12.23
144 | 笔记内容:今天学习Arbitrum的技术扩招
145 | NFT 市场：
146 | 主要包括 Stratos、tofuNFT、TreasureDAO，其中 TreasureDAO 旗下元宇宙游戏 Bridgeworld 内的 NFT 系列热度偏高。
147 | 工具/基础设施支持：
148 | 包括 Band Protocol、Biconomy、BlockVision、Chainlink、Covalent、DefiLlama、Etherscan、Nansen、Snapshot、Tenderly、The Graph、Truffle Suite 等二十多个。
149 | 节点提供方：
150 | 包括 Alchemy、Ankr、DataHub、GetBlock、Infura、Moralis 和 QuickNode。
151 | ### 2024.12.24
152 | 1. Rollup 技术的应用
153 |
154 | Arbitrum 采用 Optimistic Rollup 技术，旨在通过链下计算和链上验证实现高效扩展。其核心思想包括：
155 | 链下计算： 用户的交易和智能合约执行主要发生在链下，从而大幅降低以太坊主网的计算负载。
156 | 链上验证： 只需通过最小量的链上数据提交（如交易摘要和状态根），实现对交易真实性的验证。
157 | 欺诈证明机制： 如果用户认为某笔交易的状态更新有问题，可以提交欺诈证明（Fraud Proof）来挑战，从而确保安全性。
158 |
159 | 这种方法实现了吞吐量和安全性的平衡：在没有恶意行为的情况下，Rollup 提供了极高的性能；而在发生争议时，链上验证机制可以确保数据一致性和安全性。
160 |
161 | 2. 创新的虚拟机架构（Arbitrum Virtual Machine, AVM）
162 |
163 | Arbitrum 引入了自己的虚拟机架构 AVM，它对以太坊虚拟机（EVM）进行了优化，主要特点包括：
164 | 完全兼容 EVM： Arbitrum 的智能合约可以直接部署以太坊上的 Solidity 合约，无需修改代码，从而降低了开发者的迁移成本。
165 | 扩展性增强： AVM 针对 Rollup 的架构特点进行了优化，使得链下执行更加高效。
166 | 跨语言支持： 支持多种开发语言，除了 Solidity，还兼容 Vyper 等语言，为开发者提供了更大的灵活性。
167 |
168 | 3. 降低交易费用
169 |
170 | 通过将大部分交易和计算移至链下，Arbitrum 有效降低了以太坊主网的 Gas 费用。这一特点使得：
171 | 用户支付的费用显著低于以太坊主网，特别适合高频小额交易的场景（如 DeFi 和 NFT）。
172 | 同时，Rollup 方案减少了数据存储需求，通过压缩数据进一步降低成本。
173 |
174 | 4. 去中心化和安全性
175 | 5. 分层架构： Arbitrum 网络的设计支持多节点运行，增强了网络的去中心化特性。
176 | 欺诈证明的抗审查性： 即使是少量诚实节点，仍然可以确保网络安全，因为它们可以有效地提交欺诈证明。
177 | 以太坊主网的依赖性： Arbitrum 继承了以太坊主网的安全性，将交易数据上链记录，从而防止数据篡改。
178 |
179 | 6. 灵活的跨链交互
180 |
181 | Arbitrum 提供强大的跨链能力，支持与以太坊主网以及其他链的资产和信息交互：
182 | 用户可以通过桥接（Bridge）轻松地在 Arbitrum 和以太坊之间转移资产。
183 | 这种桥接机制兼顾了速度与安全，通常只需几分钟即可完成转账。
184 |
185 | 6. 生态系统的快速发展
186 |
187 | Arbitrum 的生态系统迅速扩展，其创新体现在：
188 | 广泛的 DeFi 支持： 许多领先的 DeFi 协议（如 Uniswap、Aave 等）已部署在 Arbitrum 上，提供与主网一致的功能但成本更低。
189 | 社区驱动的治理： Arbitrum 在其 Arbitrum One 和 Arbitrum Nova 网络中，通过引入去中心化治理（DAO）进一步增强社区参与度。
190 |
191 | 7. 创新的开发者工具
192 | Arbitrum SDK： 提供简单易用的开发工具，方便开发者快速集成 Layer 2 功能。
193 | 优越的调试环境： 开发者可以利用 Arbitrum 提供的工具对智能合约进行链下调试，大大提升开发效率。
194 | ### 2024.12.25
195 | 笔记内容:Arbitrum的生态
196 | 1. DeFi（去中心化金融）
197 | Arbitrum 是 DeFi 生态的重要组成部分，众多知名 DeFi 项目已经在其网络上部署或扩展：
198 | 交易协议：
199 | Uniswap 和 SushiSwap 等去中心化交易所（DEX）在 Arbitrum 上提供高效、低成本的交易服务。
200 | 支持 AMM 模式，同时扩展限价单等功能。
201 | 借贷协议：
202 | Aave 和 Compound 等主流借贷协议在 Arbitrum 上运行，用户可以以更低的费用参与借贷市场。
203 | 衍生品：
204 | Arbitrum 上的项目（如 GMX 和 Perpetual Protocol）专注于合约交易和杠杆衍生品，为高频交易者提供极低延迟和高效体验。
205 |
206 | 2. NFT 和游戏
207 |
208 | Arbitrum 的低费用和高吞吐量为 NFT 和区块链游戏提供了理想环境：
209 | NFT 市场：
210 | TreasureDAO 是 Arbitrum 上的知名 NFT 生态系统，建立了以 $MAGIC 为核心的元宇宙经济。
211 | Stratos 和 TofuNFT 提供多样化的 NFT 交易服务。
212 | 区块链游戏：
213 | 游戏开发者利用 Arbitrum Nova 提供的低延迟和高性能，构建了如 Smolverse 等生态。
214 | 支持 Play-to-Earn（P2E）模式，让用户参与游戏的同时获得经济回报。
215 | ### 2024.12.26
216 | 笔记内容：Arbitrum 的应用案例分析
217 |
218 | 以下是 Arbitrum 在多个领域的典型应用案例：
219 |
220 | 1. 去中心化交易所（DEX） - Uniswap V3
221 | 特点：
222 | Uniswap V3 在 Arbitrum 上运行，实现了快速、低成本的交易。
223 | 为流动性提供者（LP）带来了更高的资本效率。
224 | 优势：
225 | 交易费用仅为以太坊主网的一小部分，适合高频交易用户。
226 | 减少拥堵问题，提高交易确认速度。
227 |
228 | 2. 去中心化衍生品交易 - GMX
229 | 功能：
230 | GMX 是 Arbitrum 上的衍生品交易平台，支持现货交易和永续合约。
231 | 提供无滑点交易体验，适合专业交易者。
232 | 优势：
233 | 低 Gas 费用和即时交易结算使其成为衍生品市场的热门选择。
234 | 用户可通过质押获得平台收入分成。
235 |
236 | 3. 借贷协议 - Aave
237 | 特点：
238 | Aave 在 Arbitrum 部署后，为用户提供了低成本的借贷服务。
239 | 支持多种主流资产的抵押和借贷操作。
240 | 优势：
241 | 更低的借贷成本吸引了散户和机构用户。
242 | 大大降低了高频操作的 Gas 费用。
243 |
244 | 4. NFT 元宇宙 - TreasureDAO
245 | 项目简介：
246 | TreasureDAO 是基于 Arbitrum 的去中心化元宇宙项目，以 $MAGIC 代币为核心
247 | 构建了丰富的 NFT 和游戏生态，如 Smolverse、Bridgeworld 等。
248 | 创新点：
249 | 集成多个子项目，实现了经济系统的交互和生态协作。
250 | 用户通过参与游戏或交易 NFT 获得收益。
251 |
252 | 5. 资产桥接 - Hop Protocol
253 | 功能：
254 | Hop Protocol 是一种多链桥接工具，支持快速、安全地在以太坊和 Arbitrum 之间转移资产。
255 | 优势：
256 | 用户可以几分钟内完成资产桥接，相较传统跨链方式更高效。
257 | 为流动性提供者带来收益奖励，增强生态参与度。
258 | ### 2024.12.27
259 | 笔记内容：未来潜力与展望
260 | 1.持续扩展的 DeFi 应用
261 | 随着更多 DeFi 项目的迁移，Arbitrum 有望成为 DeFi 的重要枢纽。
262 | 低费用、高性能的特点将吸引更多高频交易和大规模金融活动。
263 | 2.区块链游戏与 NFT 的崛起
264 | Arbitrum Nova 的优化为社交和游戏应用提供了理想环境。
265 | NFT 和 P2E 游戏生态可能成为未来的增长亮点。
266 | 3.多链互操作性
267 | Arbitrum 与其他链的无缝互通将吸引更多跨链应用开发者。
268 | 随着 L2 技术的普及，Arbitrum 有望成为跨链生态的重要枢纽。
269 | 4.去中心化治理的强化
270 | 随着 Arbitrum DAO 的成熟，社区将进一步主导网络发展，增强去中心化属性。
271 | ### 2024.12.28
272 | $ARB 的基本功能
273 | 治理代币的定位
274 | $ARB 是 Arbitrum 生态的治理代币，其主要作用是赋予持有者对 Arbitrum 协议的重大决策权，包括以下内容：
275 | 治理提案投票：持有者可以对协议参数调整、技术升级、生态资金使用等事项进行投票。
276 | DAO 控制权：通过 Arbitrum DAO，$ARB 持有者能够决定网络发展的长期方向。
277 | 协议升级：任何 Arbitrum 协议的技术变更都需要经过 DAO 的治理流程。
278 | 非支付功能
279 | 与许多其他 Layer 1 区块链的代币不同，$ARB 并未设计为支付手续费的工具。Arbitrum 的交易费用仍然以 ETH 支付。这种设计确保了 ETH 的使用生态不会受到影响，同时强化了 $ARB 的治理属性。
280 | 2. $ARB 代币分配机制
281 | $ARB 的初始总供应量为 100 亿枚，代币的分配方案体现了对早期贡献者、生态支持者和未来社区发展的平衡。
282 | 具体分配比例
283 | Arbitrum DAO 资金池：42%
284 | 最大的分配比例用于 DAO 金库，为生态系统的长期发展提供资金。
285 | DAO 可以利用这些代币支持生态项目、技术开发、社区激励等。
286 | Offchain Labs 团队和投资者：44%
287 | Offchain Labs 团队（员工和顾问）：27%
288 | 作为 Arbitrum 的核心开发团队，他们获得了一部分代币激励，以推动项目持续优化和技术突破。
289 | 早期投资者：17%
290 | 这些代币分配给支持 Arbitrum 的风险投资机构和战略合作伙伴。
291 | 社区分配：13%
292 | 空投给用户和项目：11.62%
293 | 分配给早期使用 Arbitrum 的用户、DAO 成员以及支持 Arbitrum 生态的项目。
294 | 激励计划：1.38%
295 | 为未来的社区建设、合作伙伴激励预留。
296 | 其他生态开发者：1%
297 | 用于奖励对 Arbitrum 协议有特殊贡献的开发者。
298 | 代币释放计划
299 | $ARB 的分配并不是一次性释放，而是采取线性解锁机制：
300 | DAO 金库和社区分配：部分代币立即释放，其余按照生态需求逐步解锁。
301 | 团队和投资者：代币锁仓，通常有 4 年线性解锁期，且前一年无任何代币解锁。
302 | 这种释放机制有助于控制代币的市场供应量，减少价格波动，稳定生态发展。
303 | 3. $ARB 的治理模式
304 | $ARB 的设计核心是去中心化治理，它通过 Arbitrum DAO 实现了一种链上治理机制。
305 | 治理的具体功能
306 | 协议参数调整
307 | 包括交易手续费、Rollup 机制参数等。
308 | 生态资金分配
309 | DAO 控制的 42% 资金池可以通过社区提案分配，用于资助项目、激励开发者等。
310 | 技术升级
311 | 任何关于 Arbitrum One 或 Arbitrum Nova 技术的升级（如 Arbitrum Stylus、数据压缩机制等）都需社区通过提案表决。
312 | 跨链发展
313 | Arbitrum DAO 可以制定政策，支持跨 Rollup 或 Layer 3 的发展。
314 | 提案和投票机制
315 | 提案门槛：
316 | 提案者必须持有一定数量的 $ARB 或获得其他持有者的代币授权。
317 | 投票方式：
318 | 使用链上投票系统，所有治理流程完全公开透明。
319 | 决策机制：
320 | 提案需达到最低投票参与率和通过门槛，才能实施。
321 | 治理的去中心化
322 | 治理权完全由 $ARB 持有者掌控，Offchain Labs 不再直接干预网络发展。
323 | 社区可以通过提案系统表达需求并推动决策，确保治理过程去中心化。
324 | 4. $ARB 的长期价值驱动
325 | 代币价值来源
326 | $ARB 的价值主要来自其治理权，而不是作为支付或燃料工具。以下是 $ARB 的核心价值驱动因素：
327 | 治理权的稀缺性
328 | 随着 Arbitrum 网络和生态的发展，治理权的影响力和价值将不断提升。
329 | 生态资金的管理
330 | DAO 金库的代币储备是生态建设的关键资源，社区的投票权决定了这些资源的使用方向。
331 | 生态增长
332 | 随着更多项目部署到 Arbitrum 上，网络的用户和交易量增加将间接推动 $ARB 的需求。
333 | 潜在价值增长点
334 | 生态扩展：Arbitrum 不断吸引 DeFi、NFT、游戏和社交项目，带动治理活动频率上升。
335 | Layer 3 发展：通过 Layer 3 技术（如 Arbitrum Orbit）构建的子链可能进一步扩大治理的范围和复杂性。
336 | 跨链影响力：Arbitrum DAO 的决策可能影响其他链的生态协作，为治理权赋予更大的价值。
337 | ### 2024.12.29
338 | DAO 的基本概念
339 | 1.去中心化
340 | DAO不依赖于传统的中心化管理，而是通过区块链上的智能合约和成员集体决策来运行。任何决策或行为都需要成员的共识或代码中预设的规则来实现。
341 | 2.自治
342 | DAO的运行规则由智能合约定义，一旦部署在区块链上，这些规则会自动执行，减少人为干预。
343 | 3组织
344 | DAO仍然是一个有目的、有结构的组织，只不过这种组织形式是数字化的，可以由全球各地的人协作完成任务。
345 | 4.智能合约
346 | DAO的核心是智能合约。这些合约是不可篡改的代码，负责记录规则和执行组织内的各种操作，例如资金管理、成员投票等。
347 | 5代币
348 | DAO通常使用代币作为治理工具。持有代币的成员可以投票参与决策，代币还可能用作奖励或分配资源的工具
349 | 6.透明性和可追溯性
350 | 所有决策、资金流动、投票过程都记录在区块链上，公开透明，便于审计和追溯。
351 | 7.全球化与开放性
352 | 任何人只需互联网连接即可加入DAO，无需受限于地理位置或传统组织的准入门槛。
353 | 8.抗审查性
354 | DAO运行在去中心化网络上，单一实体难以审查或阻止其运作。
355 | 9.高效率的自动化
356 | 通过智能合约自动执行操作，减少人为干预和官僚流程
357 | ### 2024.12.30
358 | Arbitrum DAO 提案流程
359 | Arbitrum 是基于以太坊的扩展解决方案，其治理采用去中心化自治组织 (DAO) 的形式。以下是 Arbitrum DAO 的提案流程及关键步骤：
360 | 1. 提案起草
361 | 社区成员或开发团队对需要讨论或执行的改动提出初步想法。
362 | 起草者通常会在社区论坛 (如 Arbitrum 的 Governance Forum) 发帖，介绍提案的背景、目的、解决方案和可能的影响。
363 | 讨论阶段的目标是征集社区的反馈，改进提案的内容。
364 | 2. 温度检查投票
365 | 提案起草完成后，提交到 Snapshot 平台进行非正式的温度检查投票。
366 | 投票者通过持有 $ARB（Arbitrum 的治理代币）表达支持或反对。
367 | 通过此阶段主要判断社区对提案的兴趣和初步倾向。
368 | 3. 正式提案
369 | 如果温度检查通过，提案会升级为 AIP，并在链上进行正式投票。
370 | 提案包含详细的执行计划，如资金分配、技术实现步骤等。
371 | 提案需要满足一定的治理门槛，如最小代币持有量或投票数量，才能进入表决阶段。
372 | 4. 链上投票
373 | 使用 Arbitrum 的链上治理系统，治理代币持有者可以投票支持、反对或弃权。
374 | 每个代币持有者的投票权重与其持有的 $ARB 数量成正比。
375 | 若提案获得所需的多数支持且满足最低投票参与率（Quorum），则提案通过。
376 | 5. 提案执行
377 | 执行成功通过的提案通常依赖于 Arbitrum DAO 的智能合约。
378 | 资金调动或协议改动等提案会通过预定义的合约自动执行，确保去中心化和透明性。
379 | 6.实际案例
380 | 在本人进行谷歌搜索Arbitrum DAO的相关提案发现在2023 年 4 月，Arbitrum Foundation 提出了首个治理提案 AIP-1，计划为基金会预留约 7.5 亿枚 $ARB 用于运营和生态发展。然而，该提案因以下原因引发社区强烈反对：
381 | 提案内容过于笼统，缺乏具体的资金使用细节。
382 | 提案的某些部分在未获社区批准前就已被执行，引发对治理透明性的质疑。
383 | 结果：
384 | 社区强烈反对导致 AIP-1 提案未通过。
385 | Arbitrum Foundation 随后分拆提案，推出了 AIP-1.1 和 AIP-1.2，分别详细说明资金分配和治理改进计划。
386 | 新提案通过后，改善了社区对基金会治理透明度的信任。
387 |
388 |
--------------------------------------------------------------------------------