⚠️ 正式开始前请确保你在身体上和精神上都处于合适的状态,请刻意练习,残酷面对 🆒。为方便检索 The First Web3 URL Intensive CoLearning 简写为 WICL1st,第 2 期即为WICL2nd,第 3 期即为 WICL3rd,以此类推。
⚠️ 报名需要按要求认真填写下面 [ XXX ] 部分,方可通过报名审核,通过审核即可开始自主学习。
-
自我介绍:
Ray LXDAO 的核心贡献者,目前在负责 PGNode 产品,目标是构建一个去中心化的基础设施,持续为公共物品的建设提供资金,技能点有后端、以太坊和 solidity 合约
-
组队期待: 暂时还没有清晰的想法,但是组队时可能需要一个前端同学一起参与
-
你认为你会完成本次 Web3 URL 的残酷学习吗? Yes
-
7 月 8 日 - 7 月 14 日:
-
自我介绍:大家按要求更新上方自我介绍,方面大家互相了解,及后续自由组队方向。
-
Web3 URL 残酷共学频道报道:大家可以自由在残酷共学群里交流分享,互动答疑,根据自身学习阶段情况随时开启自由组队。
-
课前学习:了解残酷共学流程,GitHub 协作共学基础;Web3:// 协议课前学习。
-
-
7 月 15 日 - 7 月 21 日:
- 7 月 15 日 周一晚 8 点- 9 点(北京时间): 第 1 次公开课分享
- 本周共学内容: 涉及 Web3:// 的背景和演进历史;支持 Web3:// 协议的访问方式 (gateway 和 EVM browser)来浏览以太坊上面的数据;熟悉使用 Web3:// 和 EthStorage 早期测试网来部署简单的去中心化网站。
- Homework1: 见课程 PPT。
-
7 月 22 日 - 7 月 28 日
-
7 月 22 日 周一晚 8 点- 9 点(北京时间): 第 2 次公开课分享
-
本周共学内容: 涉及 Web3:// 高级开发工具,包括:在命令行通过 web3curl 来通过 Web3:// 协议下载数据,通过 ethfs-uploader 批量上传网页数据,通过 manual 模式来搭建去中心化多人交互全链网站;及深入理解以太坊的存储模型和 gas 开销等。
-
边学边用实战开发: 根据组队情况自由安排。
-
Homework2: 见课程 PPT。
-
-
7 月 29 日 - 8 月 4 日
- 7 月 29 日 周一晚 8 点- 9 点(北京时间): 第 3 次公开课分享
- 本周共学内容: 涉及实际应用案例分享及未来以太坊基础设施在 Web3:// 的重要作用及开发方向等。
- 边学边用实战开发: 根据组队情况自由安排。
- 结营分享: 具体时间及详情另在「Web3 URL 残酷共学频道」通知。
- 今日学习时间:0.5h
- 学习内容小结:今天整体看了一遍材料,Web3 url 这个协议有意思的地方在于提供了一个数据访问的前端,以一种更优雅的方式去访问链上的数据,这里有点类似各种 DAPP 的前端,比如使用 Uniswap 可以直接调用合约,但也可以使用网页来来使用。Web3 url 更进一步,是提供了一个访问链上数据的抽象,可以实现对各种链上数据的访问。明天开始深入细节。
- 今日学习时间:0.5h
- 学习内容小结:
- Web3 URL 协议的优势:
- 不会对当前基于 EVM 链的协议层做出变更,而是加了一个中间层,这个也符合软件开发的原则,没有什么是加一个中间层解决不了的,如果有,那就加两个
- 最大程度兼容 HTTP URL,可以在现有协议上做出少量的修改就可以满足要求
- 协议诞生的背景:
- 用户通过钱包签署交易,然后通过节点服务商发送数据,链上存在大量的用户提交的数据
- 但这些数据的获取对于用户来说是困难的,用户不会部署自己的节点
- 节点运营商和 dAPP 的开发者可以获取、审查这些数据,极端情况下,甚至会提供恶意的内容
- 链上数据访问,也需要一个去中心化的解决方案
- Web3 URL 协议的优势:
- 今日学习时间:0.5h
- 学习内容小结:
- Web3 url 的解决方案:
- 去掉那些中心化的依赖,比如运营商维护的节点
- 只依赖那些去中心化的协议
- TCP/IP 协议
- ENS 协议
- p2p 网络
- 基础结构:web3://[:]/
- 以 ERC-4804 为基础
- 结构与 DID 的设计有点类似,都是通过 url 本身解析出来大多数信息
- 域名解析
- 至少支持 ENS 服务,但可以根据客户端支持其他域名服务
- 跨链域名解析的标准在 ERC-6821
- Web3 url 的解决方案:
- 今日学习时间:0.5h
- 学习内容小结:
- Web3 url 定义了一套数据访问的规则,那么到具体的合约上,还是需要能将请求解析出来,有三种解析方式
- auto:智能合约是通用的,比如 ERC20,ERC721,这种情况下,将用标准的方式向 url 中添加参数,比如直接获取 balanceOf
- manual:智能合约中实现了特定的接口,可以在 url 中增加任何路径,然后智能合约返回不同的数据,就像 web2 中的接口一样
- resource request: 类似 manual,但是可以做多精细的控制,很多逻辑处理在浏览器端完成(ERC-6944)
- 客户端决定用哪种模式:
- 合约中实现 resolveMode 接口,URL 在解析之前先调用这个方法查看具体用哪种解析方式
- 问题:Web3 url 的解析最终也是要调用中心化的 RPC,怎么解决 RPC 不会作恶的问题?
- Web3 url 定义了一套数据访问的规则,那么到具体的合约上,还是需要能将请求解析出来,有三种解析方式
- 今日学习时间: 0.5h
- 学习内容小结:
- web3 Url 也需要由网关来支持,网关完成请求的解析,然后分发到不同的链上,这里其实会有一个问题
- 最终还是要调用 RPC,单一的 RPC 会带来作恶的问题,所以要调用多个 RPC 反复比对结果才能确定数据没有问题,那么这里的RPC 成本谁来负责
- 网关也是需要有人来运营,如果要足够去中心化,怎么激励其他人或者组织来运营网关,如果网关的数量不够多,那么就很容易被 ddos 攻击或者其他的作恶问题
- web3 Url 也需要由网关来支持,网关完成请求的解析,然后分发到不同的链上,这里其实会有一个问题
- 今日学习时间:0.5h
- 学习内容小结:
- 继续上回的思考,有了这样一个通用的数据接口之后,用户可以基于 DApp 完成更加复杂的逻辑,在需要在链上写入数据时,可以直接通过钱包来写入,读取数据时,直接通过 web3 url 来读取,避免了自己开发一个后台服务来写入,这种更能赢得用户的信任,也更加去中心化
- 这样一来,网关层就会承受巨大的流量,这样会带来几个问题:
- 怎么用合适的经济模型来激励更多的人来搭建网关,只有规模大了,才能防止被攻击
- 怎么防止搭建网关的人对返回的内容作恶