Skip to content

Latest commit

 

History

History
120 lines (87 loc) · 7.25 KB

Ray_WICL1st.md

File metadata and controls

120 lines (87 loc) · 7.25 KB
Raw

Web3 URL 残酷共学第 1 期残酷指引

⚠️ 正式开始前请确保你在身体上和精神上都处于合适的状态，请刻意练习，残酷面对 🆒。为方便检索 The First Web3 URL Intensive CoLearning 简写为 WICL1st，第 2 期即为WICL2nd，第 3 期即为 WICL3rd，以此类推。

⚠️ 报名需要按要求认真填写下面 [ XXX ] 部分，方可通过报名审核，通过审核即可开始自主学习。

[ 你的名字 ]

  1. 自我介绍：

    Ray LXDAO 的核心贡献者，目前在负责 PGNode 产品，目标是构建一个去中心化的基础设施，持续为公共物品的建设提供资金，技能点有后端、以太坊和 solidity 合约

  2. 组队期待： 暂时还没有清晰的想法，但是组队时可能需要一个前端同学一起参与

  3. 你认为你会完成本次 Web3 URL 的残酷学习吗？ Yes

第 1 期共学时间计划

  • 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 残酷共学频道」通知。

笔记证明 Notes Proof

07.15

  • 今日学习时间：0.5h
  • 学习内容小结：今天整体看了一遍材料，Web3 url 这个协议有意思的地方在于提供了一个数据访问的前端，以一种更优雅的方式去访问链上的数据，这里有点类似各种 DAPP 的前端，比如使用 Uniswap 可以直接调用合约，但也可以使用网页来来使用。Web3 url 更进一步，是提供了一个访问链上数据的抽象，可以实现对各种链上数据的访问。明天开始深入细节。

07.16

  • 今日学习时间：0.5h
  • 学习内容小结：
    • Web3 URL 协议的优势：
      • 不会对当前基于 EVM 链的协议层做出变更，而是加了一个中间层，这个也符合软件开发的原则，没有什么是加一个中间层解决不了的，如果有，那就加两个
      • 最大程度兼容 HTTP URL，可以在现有协议上做出少量的修改就可以满足要求
    • 协议诞生的背景：
      • 用户通过钱包签署交易，然后通过节点服务商发送数据，链上存在大量的用户提交的数据
      • 但这些数据的获取对于用户来说是困难的，用户不会部署自己的节点
      • 节点运营商和 dAPP 的开发者可以获取、审查这些数据，极端情况下，甚至会提供恶意的内容
      • 链上数据访问，也需要一个去中心化的解决方案

07.17

  • 今日学习时间：0.5h
  • 学习内容小结：
    • Web3 url 的解决方案：
      • 去掉那些中心化的依赖，比如运营商维护的节点
      • 只依赖那些去中心化的协议
        • TCP/IP 协议
        • ENS 协议
        • p2p 网络
      • 基础结构：web3://[:]/
        • 以 ERC-4804 为基础
        • 结构与 DID 的设计有点类似，都是通过 url 本身解析出来大多数信息
      • 域名解析
        • 至少支持 ENS 服务，但可以根据客户端支持其他域名服务
        • 跨链域名解析的标准在 ERC-6821

07.18

  • 今日学习时间：0.5h
  • 学习内容小结：
    • Web3 url 定义了一套数据访问的规则，那么到具体的合约上，还是需要能将请求解析出来，有三种解析方式
      • auto：智能合约是通用的，比如 ERC20，ERC721，这种情况下，将用标准的方式向 url 中添加参数，比如直接获取 balanceOf
      • manual：智能合约中实现了特定的接口，可以在 url 中增加任何路径，然后智能合约返回不同的数据，就像 web2 中的接口一样
      • resource request: 类似 manual，但是可以做多精细的控制，很多逻辑处理在浏览器端完成（ERC-6944）
    • 客户端决定用哪种模式：
      • 合约中实现 resolveMode 接口，URL 在解析之前先调用这个方法查看具体用哪种解析方式
    • 问题：Web3 url 的解析最终也是要调用中心化的 RPC，怎么解决 RPC 不会作恶的问题？

07.21

  • 今日学习时间: 0.5h
  • 学习内容小结：
    • web3 Url 也需要由网关来支持，网关完成请求的解析，然后分发到不同的链上，这里其实会有一个问题
      • 最终还是要调用 RPC，单一的 RPC 会带来作恶的问题，所以要调用多个 RPC 反复比对结果才能确定数据没有问题，那么这里的RPC 成本谁来负责
      • 网关也是需要有人来运营，如果要足够去中心化，怎么激励其他人或者组织来运营网关，如果网关的数量不够多，那么就很容易被 ddos 攻击或者其他的作恶问题

07.22

  • 今日学习时间：0.5h
  • 学习内容小结：
    • 继续上回的思考，有了这样一个通用的数据接口之后，用户可以基于 DApp 完成更加复杂的逻辑，在需要在链上写入数据时，可以直接通过钱包来写入，读取数据时，直接通过 web3 url 来读取，避免了自己开发一个后台服务来写入，这种更能赢得用户的信任，也更加去中心化
    • 这样一来，网关层就会承受巨大的流量，这样会带来几个问题：
      • 怎么用合适的经济模型来激励更多的人来搭建网关，只有规模大了，才能防止被攻击
      • 怎么防止搭建网关的人对返回的内容作恶