Saturn Goes Web3工作组

使土星网络尽可能地成为“Web3”。完全的不信任和去中心化可能还不能实现，但我们仍然有很多方法可以将表盘从Web2转移到Web3。让我们以Web2.999为目标

# #为什么?

1、 不然有什么意义呢!市场上已经有一些出色的Web2 cdn。然而，在协议实验室，我们关心的是:

内容寻址

可验证性

数据隐私和所有权

不可靠的协议

地方分权

2、 土星越Web3，协议实验室手中的责任就越少。

3、土星突然引起了Web3社区的注意！它有可能一直走下去。土星变得越Web3，它将从Web3社区获得更多的荣誉，这将导致更多的用例和采用Web3社区。相反，如果我们继续构建Web2的特性，我们就会跨过Web2的卢比孔河，无法迁移到web3架构。

# #工作组

这个工作组将包括来自RM实验室、共识实验室、CEL和CryptoNet等方面的专家，以便在正确的方向上快速取得进展。

目前土星控制平面的职责

现有的集中式土星控制平面执行以下任务，我们已将其作为工作流进行布局。我们希望把所有这些任务都变成由智能合约管理的任务。

土星工作流类别

1.可验证的支付系统

该工作流程旨在采用现有的土星支付系统，并使其尽可能可验证，同时不冒网络安全风险。欺诈检测模块目前必须保持一个黑盒，但我们如何验证支付系统呢?

- https://github.com/filecoin-saturn/zk-fraud: zk-电路，用于运行欺诈检测算法，并将产生的非脆弱性日志相加以计算支付。还提供合同来验证生成的证明。

-‣:(目前)一个分配土星奖励的支付分配器合同+部署到FEVM的脚本

-‣by @Amean Asad页面(包括支付影响评估者的图表)

一个更长期的问题是，土星最终是否应该拥有自己的代币。

2.内容管理

这个工作流程涉及土星网络上的内容管理，以及我们如何分散这些责任。

-我们能设计一个p2p的坏消息八卦网络吗?这可以按地区甚至国家来做吗?因为不同的国家对内容有不同的法律?

-我们能设计一个p2p热门内容八卦网络吗?

-原创[GossipSub](https://arxiv.org/pdf/2007.02754.pdf)论文，包括对其安全特性的分析。

# #会员管理

该工作流涉及到在成员管理类别中采用Saturn编排器的上述角色，并将它们编码到智能合约中的无信任协议中。

-我们可以使用ConsensusLab Uptime检查器来检查节点的正常运行时间吗?这可以在每个地区用非常快的ping时间完成吗?

- - - - - - [https://youtu.be/DcYEmATRfrQ?t=422] (https://youtu.be/DcYEmATRfrQ?t=422)

去中心化的协调器如何将TLS证书分配给L1节点?

—移除节点需要满足哪些条件?

-我们是否需要L1或L2节点加入网络?我们应该因为他们的不良行为而裁掉他们吗?

——[https://hackmd.io/@cryptoecon / saturn-aliens / % 2 fxzggnn_ztyewqwyrgluisa # The-minimalist-collateral] (https://hackmd.io/@cryptoecon / saturn-aliens / % 2 fxzggnn_ztyewqwyrgluisa # The-minimalist-collateral)

### IPC区域-现在需要为此进行设计，但第一个版本只是在主网上

IPC子网可用于在每个地区进行正常运行时间检查，并提供网络弹性，其中每个地区都有一个协调器。这意味着如果一个区域发生故障或区域之间的连接发生故障，每个区域都可以继续独立运行。该工作流程涉及为每个区域设计一个Saturn Orchestrator智能合约，用于执行上述成员管理。

- @Marko Vukolic的写作:[https://hackmd.io/@consensuslab/H14XvkDoj/edit](https://hackmd.io/@consensuslab/H14XvkDoj/edit)

L2节点

这个工作流程是关于我们如何允许更多的节点加入土星网络，作为每个区域的额外缓存容量。这些节点不会有与L1节点相同的带宽要求，但将负责在每个区域存储大量内容，并证明它们正在存储这些内容，这样缓存缺失就不必回到另一个区域的SP。

-对于L2s，我们应该使用什么证明机制来证明数据的可用性。

- @Thomas Chardin的L2设计页面

- https://github.com/retrieval-markets-lab/poptart:第一次尝试创建L2节点，包括一个多对等检索协议(**tork**)。

- https://github.com/retrieval-markets-lab/melon:第一次通过创建数据可用性证明(使用多项式承诺)，可以在链上验证。

- https://github.com/retrieval-markets-lab/krazyg: KZG承诺的rust实现。

开放性问题

-在这个时候，我们愿意在多大程度上牺牲用户体验来换取去中心化?

-在当前的编排和支付架构的背景下，去中心化意味着什么?

-目前的系统设计和网络布局是否有利于分散化?更具体地说，基于日志聚合的支付系统是去中心化CDN的最佳起点吗?

-我们应该优先考虑可验证性而不是去中心化吗?

##优先级和DRIs

第一次发布可验证的付款没有ZK

第一次发布没有子网

没有定期的位置证明，我们如何进行可验证的区域定位?我们需要先证明定位协议吗?

-最优先要解决的问题，可能是集中到分散的迁移:

-减少流失(赌注，声誉等)

-屏蔽不良内容。内容审核

-产品与工程的权衡

我们能否仅凭CDN的价格就获得Web2客户?

从Web3挑选客户使用土星，即使他们不能支付。

ZK和IPC区域-展望这些事情。

未来支付方式的蓝图

确保IPC工具能够支持控制平面

Dante + Amean -可验证支付智能合约，计费作为一个潜在的后续。

Thomas +共识实验室的IPC +控制平面

设计整个系统是如何运作的，以及它是如何构建的。