kyve1elar4nu0dspy8uz3fx2pfmjewwdjuruy2j7p2c

• Arweave是去中心化数据存储的协议/网络

• Arweave实现了数据的永久储存

• Arweave实现了一次付费永久储存的经济模式

• Arweave不是传统意义的链式结构，而是使用了类似图状的Weave数据结构，新节点无需同步所有旧数据

• Arweave使用SPoRA(（Succinct Proofs of Random Access，随机访问的简洁证明）)共识，该共识鼓励存储更多的数据，储存更少节点储存的数据。通过储存内容 + 算力的方式来竞争出块，更多共识细节可以参考这里

• 中间件是一类介于系统层与应用层中，掩盖系统层开发细节，直接提供应用层业务所需功能的工具

• 区块链领域的中间件可以理解为，避免了直接与底层链端交互开发，辅助上层应用进行开发的一系列工具，例如Chainlink/The Graph/Infura等都属于中间件

• KYVE是一组提供数据流标准化存储与验证的去中心化协议

• KYVE协议构建在一条基于CosmosSDK的公链Korellia上

• KYVE是Arweave生态最重要的应用之一，作为存储中间件双雄KYVE + Bundlr之一

• 链上储存扩容

  • 传统区块链类似Ethereum全节点大小已经达到700G, 日益增长的链数据会造成节点的储存压力,也就是我们常说的状态爆炸问题，不断提高着新节点加入的门槛。KYVE最主要的一项业务便是归档其它区块链的数据并储存至Arweave。区块链数据在归档到Arweave后可以压缩裁剪掉可以通过计算还原的历史中间状态数据，仅保留较近一段时间的中间状态数据和最新状态数据用作节点验证，大幅缩小储存压力。

  • KYVE使用了一种被称为Bundle的批处理技术，将多个数据进行捆绑处理，大大加快存储与验证的效率, 也降低了存储开销。某种程度上KYVE也可以看作Arweave的Rollup。

  • KYVE使用不同的Runtime模块来匹配不同类型的区块链数据类型，抓取区块数据存储后，也可以非常方便查找，提供了一定程度的检索功能了

• 链下计算扩容

  • 传统区块链例如Ethereum的节点需要同时负责执行/结算/共识/DA的工作。执行的意思就是每次智能合约的调用，几乎所有节点都需要去执行一遍计算。这样做安全性非常高但是也有显而易见的问题 - 效率很低，导致的问题大家也都清楚 - 网络堵塞，费用高昂。这个时候就出现了计算扩容的需求

  • 针对传统区块链的扩容有很多方向, 侧链/rollup/新共识/链下扩容等。链下扩容的基础思路是将执行部分放到用户本地或者单独的链下节点进行计算。好处是显而易见的，这里执行计算的机器只有一台或者少数的几台，节约了大量计算资源。而且链下机器可以针对特定计算类型进行优化，达到计算效率的最优化

  • Arweave的永久储存特性可以保证链上储存的数据不可更改性(数据可用性)，这个在链下扩容看来就像图灵机的纸带，所有的合约代码与合约运行状态都可以持续的记录到Arweave上，用户在使用时将合约代码与合约的所有运行状态同步到本地，进行一遍状态计算确保最新状态的有效性后，就可以开始执行自己的操作，最后将最新的合约状态再上传至Arweave完成链下计算的功能

  • 上面说的Arweave提供的这种链下计算方法叫做SmartWeave,是Arweave团队开发的智能合约执行环境。通过上面流程的描述可以发现一个问题，为了获得最新状态数据的有效性保证，用户在本地执行链下计算需要先下载所有历史状态数据并进行一遍验证计算。显然如果历史状态过多或者计算量巨大，用户每次实际使用前都浪费大量时间和算力在同步历史数据与验证最新状态上。KYVE通过整个网络的共识可以保证最新状态的有效性，那么借助KYVE的最新状态数据，用户便可以直接开始自己的链下计算工作了，计算完成后通过KYVE再将状态更新回Arweave。KYVE解决了上传下载过程中数据有效性这个对于链下计算扩容来说至关重要的问题

• 已有数据跨链方案的问题

  • 如今最常用的数据跨链方案大都遵循监控 - 中继模型, 在源链上会有一组合约监控具体的数据状态并生成证明文件，证明文件通过中继网络发送到目标链上。这里可以看到两个问题，源链上的监控者需要持续的监控状态变更，还需要持续生成证明文件，开销是一个问题。更重要的问题是数据信息的中继需要完全信赖中继网络，这也是整个系统最薄弱的地方。

  • 中继或者见证人的存在本质上是为了解决DA信息相互独立隔绝的问题。假如多条链的DA存放在同一个DA层上，那所有信息中继都只是DA层内的信息传递，安全性等同于DA层的安全性，那就只需监控者就可以完成跨链。

• KYVE + Arweave = DA Layer？

  • 最近很火的专注于DA的区块链Celestia最重要的一个Feature就是解决了数据跨链互操作的问题。因为所有其上的区块链都将DA数据存放其中，所以数据跨链本质上就只需要监控这一个角色了，所有中继都是链内的信息传递，这个安全性等同于区块链的安全性。之前我们讨论过KYVE保证了数据的有效性，Arweave保证了数据的可用性，那本质上KYVE+Arweave完全可以作为DA层，达到和Celestia一样的数据跨链和互操作性效果

  • KYVE相较于Celestia的优势在于获取数据的主动性。KYVE是中间件，网络内可以通过治理提案很容易的创建新的数据池来抓取特定区块链的数据。Celestia是被动获取构建于其上的执行层的数据，选择一定程度上是受限的。

  • 还有一点我们不能忘记，KYVE的底层网络Korellia是基于CosmosSDK的独立POS链。所以IBC是完全适用于KYVE的，我想像不出还有哪个网络比KYVE更适合作为Arweave与Cosmos生态的IBC接口。

• Protocol Layer

  • 协议层架构于链层之上，负责现有KYVE业务(Pools/Fund/Stake/Delegate)

  • 创建和维护各种数据池

  • 数据池内Protocol节点负责上传和验证数据

  • 数据池内Protocol节点负责达成数据有效性共识

  • 数据池内节点发送自身状态到Chain节点

• Chain Layer

  • Tendermint共识, 保存Protocol节点的状态

  • 负责保证Protocol的状态有效性(目前只有KYVE协议)

• Pools

  • 数据池可以被看做是完成收集及验数据工作的最小单位

  • 数据池内包含Funder/Protocol Staker/Protocol Delegator角色

  • 数据池的运行规则依赖runtime模块

  • 针对不同的虚拟机环境需要不同的runtime，但是相同的虚拟机环境可以复用runtime

    • @kyve/evm可以用在Ethereum上，也可以用在EVM兼容链上(Moonbeam/Aurora)

    • 对于Solana则要使用@kyve/solana

• Funder

  • Funder是每个数据池的资金来源，数据池内所有其它角色的盈利来自于Funder

  • Funder是需要使用该数据池数据的项目方或者用户，如果数据池内的funding被耗尽则该数据池会停止工作

  • 目前每个数据池只有100个Funder卡槽，目前Funder没有激励，但是不排除之后针对数据池给与Funder的特权与激励

• Protocol Staker

  • Protocol Staker是数据池内运行节点的角色，真正负责数据池内的上传验证等工作

  • 成为Protocol Staker需要质押kyve代币，如果出现不良行为(离线/上传错误数据/验证数据失误等)会造成节点内质押代币的slash

  • Protocol Staker会按工作量获得kyve代币奖励，奖励和节点代币质押量相关

• Protocol Delegator

  • 如果你不想自己运行Protocol节点, 可以选择作为Delegator, 将kyve代币质押给自己支持的Staker来分享节点的工作收益

  • Protocol Staker的不良行为也会造成在其上质押的kyve的Delegator被slash

  • Protocol Delegator可以帮助筛选出优质节点，共享网络收益

• Chain Staker

  • Chain Staker需要在Korellia网络上运行Chain节点，负责Korellia网络的有效与安全

  • Chain Staker在运行Chain节点时也需要质押kyve代币，类似于其它Cosmos生态链

• Chain Delegator

  • Chain Delegator质押代币给支持的Chain Staker来分享节点工作收益，和其它cosmos生态的链的Stake机制相同

• 金库

  • Protocol节点每次完成bundle proposal都会从Funder处获取奖励，其中1%作为网络费用会被直接扣除到金库

  • Slash的资金也会进入金库

  • 金库资金用于网络的发展与治理

• Slashing

  • 无效上传行为，会造成当事节点20%质押代币的罚没

  • 无效验证行为，会造成当事节点10%质押代币的罚没

  • 超时离线行为，会造成当事节点1%质押代币的罚没

• 为了加快KYVE中数据验证的效率，所有数据在被上传前都被打包成bundle，这样在一个验证轮内可以同时处理多个数据，数据流也可以被拆分至多个验证轮中执行。

• 1. 选择一个Uploader

  • 每一个验证轮由选举此轮的Uploader开始

  • Uploader的选择与节点staker的质押量以及Delegation数量相关

• 2. 创建Bundle Proposal

  • 上面选择出来的Uploader按照设定的upload_interval去收集数据

  • 一旦收集到足够数据，数据就被发到buffer进行gzip压缩

  • 最后创建一个bundle proposal之后供其它validator进行验证

• 3. 上传Bundle到Arweave, 将上传信息同步到Kyve网络

  • Uploader将上面打包完成的bundle上传至Arweave

  • 将Arweave返回的上传记录以及其它上传信息同步至网络中

• 4. Validator验证Bundle的有效性

  • 当Uploader将上传记录和其它bundle信息同步到网络后，validator便开始对数据有效性进行验证

  • validator会从Arweave下载原始bundle数据，解压缩，然后把数据解析到原始json格式，然后和源数据进行一次哈希比对

  • 最后validators通过对proposal的投票来达成数据有效性的共识

• 5. 达成网络状态的最终性

  • 如果超过一半的validator确认数据的有效性，则达成网络状态的最终性，此Bundle Id也可以被提供给外部使用

  • 网络内奖励的分配

• Arweave

• Solana

• Near

• Avalanche

• Mina

• Cosmos

• Moonbeam

• Aurora

• Octopus

• Celo

• Zilliqa

The KYVE Network | KYVE

五分钟读懂 KYVE：基于 Arweave 的跨链存储中间件

Arweave: The Permanent Storage Experiment - Delphi Digital

A Storage-based Computation Paradigm Enabled by Arweave | by outprog | everFinance | Medium

kyve1elar4nu0dspy8uz3fx2pfmjewwdjuruy2j7p2c

• Arweave是去中心化数据存储的协议/网络

• Arweave实现了数据的永久储存

• Arweave实现了一次付费永久储存的经济模式

• Arweave不是传统意义的链式结构，而是使用了类似图状的Weave数据结构，新节点无需同步所有旧数据

• Arweave使用SPoRA(（Succinct Proofs of Random Access，随机访问的简洁证明）)共识，该共识鼓励存储更多的数据，储存更少节点储存的数据。通过储存内容 + 算力的方式来竞争出块，更多共识细节可以参考这里

• 中间件是一类介于系统层与应用层中，掩盖系统层开发细节，直接提供应用层业务所需功能的工具

• 区块链领域的中间件可以理解为，避免了直接与底层链端交互开发，辅助上层应用进行开发的一系列工具，例如Chainlink/The Graph/Infura等都属于中间件

• KYVE是一组提供数据流标准化存储与验证的去中心化协议

• KYVE协议构建在一条基于CosmosSDK的公链Korellia上

• KYVE是Arweave生态最重要的应用之一，作为存储中间件双雄KYVE + Bundlr之一

• 链上储存扩容

  • 传统区块链类似Ethereum全节点大小已经达到700G, 日益增长的链数据会造成节点的储存压力,也就是我们常说的状态爆炸问题，不断提高着新节点加入的门槛。KYVE最主要的一项业务便是归档其它区块链的数据并储存至Arweave。区块链数据在归档到Arweave后可以压缩裁剪掉可以通过计算还原的历史中间状态数据，仅保留较近一段时间的中间状态数据和最新状态数据用作节点验证，大幅缩小储存压力。

  • KYVE使用了一种被称为Bundle的批处理技术，将多个数据进行捆绑处理，大大加快存储与验证的效率, 也降低了存储开销。某种程度上KYVE也可以看作Arweave的Rollup。

  • KYVE使用不同的Runtime模块来匹配不同类型的区块链数据类型，抓取区块数据存储后，也可以非常方便查找，提供了一定程度的检索功能了

• 链下计算扩容

  • 传统区块链例如Ethereum的节点需要同时负责执行/结算/共识/DA的工作。执行的意思就是每次智能合约的调用，几乎所有节点都需要去执行一遍计算。这样做安全性非常高但是也有显而易见的问题 - 效率很低，导致的问题大家也都清楚 - 网络堵塞，费用高昂。这个时候就出现了计算扩容的需求

  • 针对传统区块链的扩容有很多方向, 侧链/rollup/新共识/链下扩容等。链下扩容的基础思路是将执行部分放到用户本地或者单独的链下节点进行计算。好处是显而易见的，这里执行计算的机器只有一台或者少数的几台，节约了大量计算资源。而且链下机器可以针对特定计算类型进行优化，达到计算效率的最优化

  • Arweave的永久储存特性可以保证链上储存的数据不可更改性(数据可用性)，这个在链下扩容看来就像图灵机的纸带，所有的合约代码与合约运行状态都可以持续的记录到Arweave上，用户在使用时将合约代码与合约的所有运行状态同步到本地，进行一遍状态计算确保最新状态的有效性后，就可以开始执行自己的操作，最后将最新的合约状态再上传至Arweave完成链下计算的功能

  • 上面说的Arweave提供的这种链下计算方法叫做SmartWeave,是Arweave团队开发的智能合约执行环境。通过上面流程的描述可以发现一个问题，为了获得最新状态数据的有效性保证，用户在本地执行链下计算需要先下载所有历史状态数据并进行一遍验证计算。显然如果历史状态过多或者计算量巨大，用户每次实际使用前都浪费大量时间和算力在同步历史数据与验证最新状态上。KYVE通过整个网络的共识可以保证最新状态的有效性，那么借助KYVE的最新状态数据，用户便可以直接开始自己的链下计算工作了，计算完成后通过KYVE再将状态更新回Arweave。KYVE解决了上传下载过程中数据有效性这个对于链下计算扩容来说至关重要的问题

• 已有数据跨链方案的问题

  • 如今最常用的数据跨链方案大都遵循监控 - 中继模型, 在源链上会有一组合约监控具体的数据状态并生成证明文件，证明文件通过中继网络发送到目标链上。这里可以看到两个问题，源链上的监控者需要持续的监控状态变更，还需要持续生成证明文件，开销是一个问题。更重要的问题是数据信息的中继需要完全信赖中继网络，这也是整个系统最薄弱的地方。

  • 中继或者见证人的存在本质上是为了解决DA信息相互独立隔绝的问题。假如多条链的DA存放在同一个DA层上，那所有信息中继都只是DA层内的信息传递，安全性等同于DA层的安全性，那就只需监控者就可以完成跨链。

• KYVE + Arweave = DA Layer？

  • 最近很火的专注于DA的区块链Celestia最重要的一个Feature就是解决了数据跨链互操作的问题。因为所有其上的区块链都将DA数据存放其中，所以数据跨链本质上就只需要监控这一个角色了，所有中继都是链内的信息传递，这个安全性等同于区块链的安全性。之前我们讨论过KYVE保证了数据的有效性，Arweave保证了数据的可用性，那本质上KYVE+Arweave完全可以作为DA层，达到和Celestia一样的数据跨链和互操作性效果

  • KYVE相较于Celestia的优势在于获取数据的主动性。KYVE是中间件，网络内可以通过治理提案很容易的创建新的数据池来抓取特定区块链的数据。Celestia是被动获取构建于其上的执行层的数据，选择一定程度上是受限的。

  • 还有一点我们不能忘记，KYVE的底层网络Korellia是基于CosmosSDK的独立POS链。所以IBC是完全适用于KYVE的，我想像不出还有哪个网络比KYVE更适合作为Arweave与Cosmos生态的IBC接口。

• Protocol Layer

  • 协议层架构于链层之上，负责现有KYVE业务(Pools/Fund/Stake/Delegate)

  • 创建和维护各种数据池

  • 数据池内Protocol节点负责上传和验证数据

  • 数据池内Protocol节点负责达成数据有效性共识

  • 数据池内节点发送自身状态到Chain节点

• Chain Layer

  • Tendermint共识, 保存Protocol节点的状态

  • 负责保证Protocol的状态有效性(目前只有KYVE协议)

• Pools

  • 数据池可以被看做是完成收集及验数据工作的最小单位

  • 数据池内包含Funder/Protocol Staker/Protocol Delegator角色

  • 数据池的运行规则依赖runtime模块

  • 针对不同的虚拟机环境需要不同的runtime，但是相同的虚拟机环境可以复用runtime

    • @kyve/evm可以用在Ethereum上，也可以用在EVM兼容链上(Moonbeam/Aurora)

    • 对于Solana则要使用@kyve/solana

• Funder

  • Funder是每个数据池的资金来源，数据池内所有其它角色的盈利来自于Funder

  • Funder是需要使用该数据池数据的项目方或者用户，如果数据池内的funding被耗尽则该数据池会停止工作

  • 目前每个数据池只有100个Funder卡槽，目前Funder没有激励，但是不排除之后针对数据池给与Funder的特权与激励

• Protocol Staker

  • Protocol Staker是数据池内运行节点的角色，真正负责数据池内的上传验证等工作

  • 成为Protocol Staker需要质押kyve代币，如果出现不良行为(离线/上传错误数据/验证数据失误等)会造成节点内质押代币的slash

  • Protocol Staker会按工作量获得kyve代币奖励，奖励和节点代币质押量相关

• Protocol Delegator

  • 如果你不想自己运行Protocol节点, 可以选择作为Delegator, 将kyve代币质押给自己支持的Staker来分享节点的工作收益

  • Protocol Staker的不良行为也会造成在其上质押的kyve的Delegator被slash

  • Protocol Delegator可以帮助筛选出优质节点，共享网络收益

• Chain Staker

  • Chain Staker需要在Korellia网络上运行Chain节点，负责Korellia网络的有效与安全

  • Chain Staker在运行Chain节点时也需要质押kyve代币，类似于其它Cosmos生态链

• Chain Delegator

  • Chain Delegator质押代币给支持的Chain Staker来分享节点工作收益，和其它cosmos生态的链的Stake机制相同

• 金库

  • Protocol节点每次完成bundle proposal都会从Funder处获取奖励，其中1%作为网络费用会被直接扣除到金库

  • Slash的资金也会进入金库

  • 金库资金用于网络的发展与治理

• Slashing

  • 无效上传行为，会造成当事节点20%质押代币的罚没

  • 无效验证行为，会造成当事节点10%质押代币的罚没

  • 超时离线行为，会造成当事节点1%质押代币的罚没

• 为了加快KYVE中数据验证的效率，所有数据在被上传前都被打包成bundle，这样在一个验证轮内可以同时处理多个数据，数据流也可以被拆分至多个验证轮中执行。

• 1. 选择一个Uploader

  • 每一个验证轮由选举此轮的Uploader开始

  • Uploader的选择与节点staker的质押量以及Delegation数量相关

• 2. 创建Bundle Proposal

  • 上面选择出来的Uploader按照设定的upload_interval去收集数据

  • 一旦收集到足够数据，数据就被发到buffer进行gzip压缩

  • 最后创建一个bundle proposal之后供其它validator进行验证

• 3. 上传Bundle到Arweave, 将上传信息同步到Kyve网络

  • Uploader将上面打包完成的bundle上传至Arweave

  • 将Arweave返回的上传记录以及其它上传信息同步至网络中

• 4. Validator验证Bundle的有效性

  • 当Uploader将上传记录和其它bundle信息同步到网络后，validator便开始对数据有效性进行验证

  • validator会从Arweave下载原始bundle数据，解压缩，然后把数据解析到原始json格式，然后和源数据进行一次哈希比对

  • 最后validators通过对proposal的投票来达成数据有效性的共识

• 5. 达成网络状态的最终性

  • 如果超过一半的validator确认数据的有效性，则达成网络状态的最终性，此Bundle Id也可以被提供给外部使用

  • 网络内奖励的分配

• Arweave

• Solana

• Near

• Avalanche

• Mina

• Cosmos

• Moonbeam

• Aurora

• Octopus

• Celo

• Zilliqa

The KYVE Network | KYVE

五分钟读懂 KYVE：基于 Arweave 的跨链存储中间件

Arweave: The Permanent Storage Experiment - Delphi Digital

A Storage-based Computation Paradigm Enabled by Arweave | by outprog | everFinance | Medium