Code Monkey home page Code Monkey logo

rfcs-deprecated's Introduction

Darwinia Introduction

Darwinia Network provides developers the scalability, cross-chain interoperability, and NFT identifiability, with seamless integrations to Polkadot, bridges to all major blockchains, and on-chain RNG services.

More details can be obtained through Darwinia Genepaper.

RFCs

Darwinia RFCs(Request for comments) describe standards for the Darwinia Network, including core protocol specifications, client APIs, and standards proposals.

The protocol and standard research’s work is divided into two parts. The first part comes from the community. Darwinia Network accepts any RFC submission from the community, including new additions, improvements and modifications. These RFCs will be open to the community and fully discussion and research to reach a consensus. The second part is from the core research team, which is responsible for organizing RFCs, organizing RFC peer audits and security audits, using Darwinia Network governance models and tools for protocol governance and voting, and forming a final agreement design draft for delivery to the protocol development team.

The submission and management of RFC documents is currently carried out on Github and can be accessed if you are interested.

Contributing

Discuss RFCs

If you are going to comment on some existing RFCs, or maybe just come acrross some good ideas and thought on the Darwinia Network. You can simply creating a new issue on the Github Issues.

The recommended language is English, and make sure that questions and information are well organized and formated, so that others can easier to understand and communite with you. One more thing, be sure to following the Github issues conventions such as good tagging and stay in topic.

Propose New RFCs

First review RFC-0007, this could also be seen as a RFC template.Then clone the repository and add your RFC to it. Then submit a Pull Request to Darwinia's RFCs repository.

The RFC source files are required to be in markdown format. Typora is a editor recommended for editing markdown files, it also have a good support for inline and Latex Formula. To view the Formulas in web browser, there is a chome Mathjax Plugin to help correctly render Latex Formulas in markdown documents in Github.

Translation

If the status of the RFC are published or final, you can contribute by helping with the translation. This project use Crowdin to cope with translations.

If you are ready, just go to https://crowdin.com/project/darwinia-network-rfcs .

rfcs-deprecated's People

Contributors

dependabot[bot] avatar freehere107 avatar hackfisher avatar robinwei-itering avatar sekisamu avatar yanganto avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

rfcs-deprecated's Issues

Darwinia Gas Model Design, follow up on deprecated RFC-0002


rfc: 2
title: 0002-darwinia-gas-model
status: Draft
desc: 达尔文网络的燃料费模型

  • 功能描述: 达尔文网络的燃料费模型
  • 开始时间: 2019-04-28
  • RFC PR: None
  • Github Issue: None

概要

达尔文网络的所有手续费总称燃料费,包括交易费用,合约执行费用,网络带宽费用,存储费用等等。EOS和波场引入的一些带宽和存储,仍然会带来一些认知门槛,所以倾向于不区分带宽和内存,都以燃料费代称。

燃料费等于燃料gas的数量乘以单位gas的价格gas price。gas price以氪石定价,因此达尔文网络将使用RING作为燃料费。

动机和目的

达尔文网络需要一个合理的燃料费模型来实现两个目的:

  • 矿工或者验证人足够的激励为系统工作来保持系统运转
  • 用户需要有足够低的门槛,可以让新手不需要付费即可发起网络交易。
  • 合约开发者也可以帮助用户支付燃料费。(参考波场的设计和实现)

Guide-level explanation

KTON可以使用获得系统的收入分成,在第一个版本的以太坊大陆和波场大陆中,氪石的分成通过通道代理实现了几乎实时的分成,但是在后续的版本这个特性将会稍作改变。当氪石相关功能迁移到达尔文网络中时,氪石获得的RING分成将会先在系统中锁定一个星期,一个星期到期后才可以提取到账户中用于转账等功能。

默认情况下,当用户发起一笔交易时,需要支付相应的RING作为燃料费,但是系统会优先从该账户的氪石锁定RING中扣去需要的燃料费,如果不够,再从账户的RING余额中扣除。

通过支持这个功能,我们将可以通过让新用户获得一定数量免费氪石的方式,定期获得燃料费,用于在进化星球达尔文网络和大陆(游戏)应用链中进行交易。

通过开发Faucet服务,可以支持免费发放燃料氪石(锁定),帮助用户降低门槛。新玩家通过prove of person(POP)获得系统faucet免费获得的氪石作为燃料,可以通过设立基金会一次性抵押一些RING生成氪石用于发放。随着时间推移,氪石的通胀会将早期Faucet免费发放氪石的成本拉低。

简化的用户案例可以是,例如用户手机号注册后就有少量氪石。

关于用户持续获得氪石的问题,一方面可以引导付费后到银行换得氪石,另一方面可以持续利用活跃时间证明到faucet换取氪石。

Reference-level explanation

[WIP]

缺点

[WIP]

理由

  • 出于用户认证门槛的考虑,不区分网络和带宽
  • 在以太坊gas模型的基础上,借助于系统收入分成,锁定分成可以用于支付燃料费等业务应用,获得了类似抵押获得燃料费的同等效果。
  • 保留gas price,让费用市场得以发挥作用和保留

现有技术

在以太坊黄皮书以及Parity Substrate中已经有了一些经典设计和实现参考:

问题

  • 矿工和验证人是否得到足够强的激励来工作。(于此相关的一个问题是,目前由于RING设置了硬顶而无法通过通胀的方式给到矿工足够激励,需要从经济层面综合考虑一下)
  • EOS和波场将燃料费分成了带宽和网络,感觉是为了更加精确的让市场调节资源,但是却极大的增加了用户的认知门槛,所以在达尔文的网络模型中没有使用这个方式。EOS和波场采取这个方式是否还有其他原因。

未来的可能性

费用市场设计

基本的费用市场实现可以参考以太坊目前的设计,当时最近也有一些关于费用市场的最新研究,可以解决目前设计的一些重要缺陷,帮助最大化矿工收入和用户体验,达尔文网络将会在设计最终定型前引入这部分的研究成果。具体的内容可以参考[2][3]。

最终达尔文设计时,出去用户体验和需求方面的考虑,还可以考虑再简化一下,以降低gas price的认知门槛。当网络不拥堵时,问题不大,也就是一般的gas price也会打包,所以不会影响新用户进来,网络拥堵资源受限时,可以提高gas price,作为应用链可以在保证用户体验情况下提供推荐gas price。

基于氪石的燃料费模型

原来考虑过一种基于KTON的通胀燃料费模型,但是因为模型太复杂而遭到丢弃,可以作为参考。

每个区块里面收集的燃料费用将会进入一个矿工氪石池,这个矿工氪石池将会按持有氪石的比例获得来自系统的RING分成(目前氪石分成的比例为系统收入的30%)。矿工氪石池的RING收入将会用于支付Validator的区块奖励,每天的区块的总奖励可以按照当前池子里剩余RING的1/28发放,每个区块的奖励可以相应算得。

KTON作为燃料费的模型

假设矿工氪石池的初始RING余额为 S, 后续每天的平均收入为 M,则第N天中池子的余额为:

也就是

因此每天的RING区块奖励将趋近于矿工氪石池每天的平均收入M。

通过Faucet免费发放燃料氪石(锁定),帮助用户降低门槛

新玩家通过prove of person(POP)获得系统faucet免费获得的氪石作为燃料,可以通过设立基金会一次性抵押一些RING生成氪石用于发放。随着时间推移,氪石的通胀会将早期Faucet免费发放氪石的成本拉低,矿工的收入来自系统收入的一部分,收入多报酬多也比较合理。

简化的用户案例可以是,例如用户手机号注册后就有少量氪石。

关于用户持续获得氪石的问题,一方面可以引导付费后到银行换得氪石,另一方面可以持续利用活跃时间证明到faucet换取氪石。

参考

关于Staking机制设计的思考(一)

问题描述

如果说PoW和PoS只是矿工/Validator关心的话题,那么Staking无疑把整个利益分配格局扩大到了生态的每一个参与者。整个生态里, validator、重度参与者、轻度使用者都共同作用塑造了整个生态。

对波卡来说,因为token没有cap,所以validator奖励是浮动的,可以更加灵活地塑造出共赢的staking模式,弱化了validator之间的竞争关系。

而对于darwinia来说,token存在cap是一把双刃剑。一方面cap的存在可以强化价值共识;而另一方面,因为有cap,在现有的模式下,就难以避免地导致某段时间内的增发是由公式决定,相对固定的,也是有cap的。

对于有cap的奖励,节点们之间相当于都在参加一个零和博弈,会导致节点之间的恶性竞争,不利于共建生态。

解决办法

1. 责任和权利对等

目前比较初级的一个解决办法,就是权责对等。validator的责任是出块,维护网络稳定。那么validator的奖励就和出块数成正比,建议这部分奖励剔除票数的影响。

2 . 分配方式改进

目前每个分红era的奖励都有cap,为了保证darwinia token 100亿上限不被打破。但是继续细分到每一轮分红era,是否可以有更加灵活的分配方式(借鉴波卡),让validator的竞争局面走出零和,这样才能更好地扩大生态。

XClaim的喂价机制对NFT不友好

XClaim似乎是在一边锁定,另一边超额抵押后获取一个与原通证价值相当的等价物。如果是这样的话,那这更像是个金融衍生品,而且非常依赖抵押物和原通证的喂价,而NFT的价格发现是很低效的。

关于出块时间设定

波卡测试网目前10s/per block,建议follow,或者在压测之后适当降低,还应考虑链本身的业务复杂度。

The importance of "Relay chain" in Token Resolution System

这里是否需要强调中继链?提到中继链往往暗含该链同时提供消息转接服务,且PTRS只为经过体系的通证提供服务。而实际上运行着PTRS的区块链网络比如达尔文提供着公共服务,跨链消息未流经该链的通证信息,只要事先进行了通证注册,它们的相关信息也会被主动收集。

Appchain Design, follow up on Deprecated RFC-0006


rfc: 6
title: 0006-dawinia-appchain
status: Draft
desc: 达尔文应用链(Darwinia AppChain)

  • 功能描述: 达尔文应用链(Darwinia AppChain)
  • 开始时间: 2019-05-13
  • RFC PR: None
  • Github Issue: None

概要

drawing_appchain

达尔文应用链简介

达尔文网络有一条枢纽链,被称为达尔文主链(Darwinia Hub),可以作为ParaChain接入Polkadot,但是同时这个达尔文主链也被设计成一个Relay链,可以让各种的游戏链接入进来,为了方便游戏开发商和其他应用在不需要懂得太多区块链知识的基础上可以开发满足应用层面需求的区块链网络,达尔文网络基于Substrate和达尔文区块链内核(Darwinia Kernel),设计开发一套应用区块链的框架,被称为达尔文应用链(Darwinia AppChain)。

首先达尔文应用链的设计目标是为了满足应用层面,甚至是业务层面的需求,而不是公链的平台需求,因此需要重视框架的灵活性,组件的多样性,在共识算法,出块速度,治理模式上与公链也会非常不同。

达尔文主链的主要设计目的是为了支持游戏的开放经济规则(跟Defi有点相似),以及游戏资产的跨链,因为不适合作为游戏应用的区块链框架直接使用,因此需要区分出达尔文网络和应用链在概念上的区别。

达尔文应用链同样基于Substrate框架,使用与达尔文链同样的内核,同时达尔文应用链可以作为ParaChain连接至达尔文链。达尔文主链和应用链组成的网络被称之为达尔文网络。

动机和目的

  • 需要设计一个灵活的区块链框架和组件集,以支持应用层面的区块链开发需求和账本需求,包括未来进化星球大陆所需要运行的区块链网络
  • 需要一个支持Darwinia ParaChain接口的区块链框架,帮助构建达尔文网路,并且帮助应用对接至外部区块链网络。
  • 应用层面的需求与目前主链的需求和设计目标的不一致

Guide-level explanation

达尔文主链与各应用链(包括大陆所在应用链)的关系(示意图WIP)

达尔文应用链示意图

其他架构参考

参考和实现

代码库

[WIP] https://github.com/evolutionlandorg/darwinia-appchain

基于达尔文应用链的进化星球大陆(WIP)

除了该大陆应用层面的需求之外,该大陆可能还会支持达尔文主链部分核心功能,这部分的支持是过渡性的,在达尔文主链上线后将迁移至主链。

达尔文企业应用链(Darwinia Enterprise AppChain)

drawing_enterprise_appchain

达尔文企业应用链(简称 DEAC)会增加一些企业需要的可插拔组件和联盟链组件,因此也可以归类为联盟链范畴。DEAC适用于希望使用达尔文内核和组件的企业用户和行业用户。

达尔文企业应用链可以选择连接至达尔文网络,实现跨链资产的对接,也可以不用连接至达尔文网络。

主要特性[WIP]

  • 支持合约
  • 应用开发者可以为用户支付燃料费
  • Finality比较好的简单共识算法
  • 支持多种密码学算法ECDSA, EDDSA,Schnorr,BLS
  • TPS高,出块速度快
  • 支持进化星球星际资产编码标准

缺点

[WIP]

理由

  • 应用层面降低用户门槛和改善用户体验的需要
  • 面向应用定制化的需要

现有技术

问题

[WIP]

未来的可能性

  • 改善存储模型
  • 适合应用开发者的治理机制
  • 满足企业用户需要

参考

More details about the relationship between validators and collators?

  1. Who will pay the collators? and in which token? DOT or native token.
    From the wiki, seems it will get paid from validators and the block market.

  2. Who will elect the collators? Validators or the parachain(and it's consensus/governance)?

  3. If the collators are part of the parachain, can the parachain collude/cooperate to monopoly the position of collator, then validators will have no other choice?

How to deploy flyclient on Chain Relay without forking BTC/Ethereum?

The FlyClient paper requires MMR to be included in the block header, thus the chain need to be hardfork/softfork/velvet fork any of these requires changes in the miner nodes of the network which is third party dependent and community driven.

So we need to find a solution for Chain Relays to fetch the correct MMR without forking BTC/Ethereum.

Here I propose a way of recursive challenging the MMR value with the assumption that at least one of the witness relay workers has the correct value and economic rational.

Because the MMR is outside of blockheader and blockhash, so the POW works does not include it, thus MMR does not reach Nakamoto Consensus and an extra challenge mechanism need to be introduced to resolve this.

Anyone can summit blockheader with a MMR attached and collateral guarantee its correctness, if no one challenge it in the defined time, the MMR will be confirmed by the chain relay and the collateral can return back to the original worker. But, if there is another one challenge the MMR value, the conflicts MMRs will transit to an gaming status, untils someone else can give proof through prev_hash by recursively summit MMRs.

The maximum complexity of the progress is Log(N), and any economic rational attacker will not continue with the recursive attack progress because he is against all the honest workers and will lose all the collateral ultimately.

[Question] RFC-0010: 其他跨链共享数据

目前通证标准主要的设计是针对所有权信息进行记录,但是并没有对通证的跨链转账,使用权,类型,生产商等信息进行记录,使得通证合约对通证的描述并不全面,也没有提供可扩展的方法来增加其他的信息。

设计通证解析系统的一个额外好处是,因为可以把中继链看做一个共享的模块(共享存储和共享运行时SPREE)。我们引入Token解析合约(脚本)来记录和更新Token的协议、跨链、权利和其他信息。

对于Polkadot架构,可以通过接入SPREE模块,在解析合约内定义约束条件,例如全局的通证总量,发行规则,并部署至SPREE模块,可以实现中继网络管辖范围的验证和可信互操作。

[Solution to nft pricing in cross-chain] XClaim + harberger tax

it's a solution to #16

问题描述

XClaim提供了一种对于fungible token友好安全的跨链解决方案,paper链接.

在安全方面,部分关键点如下:
Pricing: 需要一个oracle来获取chain I 上的native token i 对chain B上的native token b 的价格关系;
Over-collateralize: 在抵押的总价值和真实价值之间需要有一定的容错空间, buffer , 来保证价格波动时的安全。参考DAI.

以上两点均有一个前提,即 ib 均需要有良好的流动性来保证定价。这对于fungible token相对更容易实现。
但是对于non-fungible token, 定价困难和流动性匮乏导致了XClaim在NFT跨链流转时,有较大的局限性。

Oracle在NFT定价上的缺陷

因为定价是抵押的基础,所以解决了定价的问题,某种程度上,也就解决了足额/超额抵押的问题,从而保证了跨链的安全性。
在XClaim方案中,主要通过Oracle实现了喂价。但是Oracle在NFT定价中,有以下缺点:

  1. NFT market市场规模小,流动性差;
  2. NFT交易所太少,主观偏差大;
  3. 每次跨链之前,均需要创建拍卖提供价格,用户操作成本高;

因此,在对待NFT的跨链上,需要有不一样的价格发现机制。

解决方案: XClaim + harberger tax

what is harberger tax

https://vitalik.ca/general/2018/04/20/radical_markets.html?source=post_page-----c2c99e866f87----------------------
https://talk.darwinia.network/topics/99

harberger tax in NFT bridging

假设目前全网已经存在了一些 vaults 并且抵押了一些 i ,当用户想chain B 上的NFT nft_b 跨到chain I上时,需要:

  • (i) 自己对 nft_b 声明一个价格 price_b ;
  • (ii) 在chain I 确认当前是否有足够collateral i (| i | = | price_b |);
  • (iii) 如果(i)和(ii)成功通过的话,用户承诺一笔跨链金额,fee_ratio * price_b 用于支付跨链手续费;
  • (iv) 如果 nft_b 在跨链中丢失或者发生了其他恶意操作的话,那么相应的 vault 会被扣除 price_b 等值的 i ,用于弥补用户的损失;如果跨链成功,这笔手续费就会被支付给相应的 vault .

here, harberger tax is more than taxation, it is an insurance and a way of price-finding.

优点

  1. 定价无需依赖oracle,在市场规模和流动性不足时,也可以定价成功;
  2. 用户无需去外部的NFT交易所再单独实行定价操作;
  3. 定价和成本之间存在线性关系,会给到 vault 足够的incentive

延伸

based on XClaim + harberger tax, 我们已经可以提供了基本的跨链价值保障。与此同时,我们也获得了一些价格发现机制,也可被视作某种pricing DAO,在此之上,也有机会发展成为NFT DEX protocol. (待续)

[Question] RFC-0010: 兼容其他跨链设施

因为NFT对可识别性的高要求,使得在跨链时,使用不同跨链设施可能会造成意想不到的后果。而Fungible Token则只要保证价值对称、资产安全即可。

可以想象以下场景:

nft(A, X, 1) 表示在A链上、合约X中标识为1的NFT

Alice在跨链桥M中,将nft(A, X, 1) 变为 nft(B, Y, 2) ;又通过跨链桥N,将nft(B, Y, 2) 变为 nft(C, Z, 3)。之后,当Alice想继续使用跨链桥M将C链上的nft 跨链去 A链的话,跨链桥M会将 nft(C, Z, 3) 识别为新的token,很可能在跨回A链时,将不再是nft(A, X, 1),而是nft(A, X, 5). NFT就丢失了自己的可识别性,或者是用户就丢失了自己的资产。

为了尽可能减少丢失NFT可识别性对用户造成的潜在资产损失,用户可以获取到Bridge Core上某个NFT当前的UNFO,之后,用户先使用其他跨链设施将NFT跨到UNFO中type记录的对应链之后,再使用Bridge Core 进行后续的跨链操作。

这样,至少在当前系统内,NFT可保证可识别性不被破坏。

在补充章节IV中,我们还将探索其他的兼容方案,例如NFT解析模块。

How will user pay the transaction fees on the parachain, native token? DOT? or both?

  1. Are users required to pay DOT for calling modules in SPREE? And are there any other methods for cross-chain interoperation except using SPREE?

  2. A lot of parachains are designing their own native token for paying tx fees, will there be user experience challenge if users are required to pay two or more fees?

  3. If cross-chain calling are in a way of calling methods in another parachain, does user require to pay the calling in that parachain's native token, which will be a problem for users too.

  4. If users requires to get DOT, how will they exist in parachain.

How parachain collators get incentived in connection model?

Here is some introduction about collaters:
https://wiki.polkadot.network/en/latest/polkadot/learn/parachains/#collators

Parachains are operated and new blocks are authored by collator nodes that maintain "full-nodes" of a particular parachain. They retain all necessary information to be able to propose new blocks and execute transactions in a similar way as miners do in traditional PoW blockchains. A block proposed by a collator node will be checked by the validator node before it is accepted as a canonical state transition by the relay-chain.

Can the validators in Solo model continue contributing as collators (get reward at the same time) after darwinia switching to connection module?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.