Fountain（FTN）：基于贡献证明的区块链化内容生态系统

首页 > 币界资讯 > 竞争币新闻 2019-03-08 11:11:42

Fountain 是一个基于贡献证明 ( Proof of Contribution ) 的区块链化内容生态系统。通过一套公开透明的贡献证明规则，运用区块链技术记录所有参与者的贡献，精准计算后，对所有参与者给予token奖励。这将有效地激励人们深度参与某个内容社区应用和整个生态，贡献自己的力量。随着生态的不断成熟和发展，Fountain 上将有丰富的内容社区应用，并且作者、读者、策展者、IP 投资者、出块节点、应用开发者等诸多角色都将从 token 中获得理应属于他们的收益。最终实现我们的愿景：一个多方共赢的、可持续发展的内容生态系统。Fountain 的核心理念，源于传统互联网内容社区应用所存在的问题：内容社区应用的用户为社区做出了巨大贡献，但却无法获得有效的贡献证明和奖励。

Token

我们认为社区中所有用户的行为都具有价值，或多或少地给社区做出了贡献，于是我们设计了 token 以证明这些贡献。所有 token 构成了整个 Fountain 生态的价值，Fountain 的 token 我们称之为 FTN。FTN 是 Fountain 最基础的价值记录单位。有两种 FTN 获取方式。通过对社区的贡献获得，或者通过市场交易获得。其中前者更为关键，因为社区必须有用户付出时间的贡献，才能增加社区的整体价值。因此，我们必须设计一套有效激励生态的 PoC ( Proof of Contribution ) 机制，用以衡量所有社区用户的贡献，并依此给予 token 的奖励。FTN 初始总量为30亿。

其中15亿个将作为基金会预留金，将用于初期社群共识建设、合作方测试、核心团队的长期激励、日常经营和投资等用途。同时预留金也将用于抑制有可能被大投资人所操纵的短期炒币投机行为。其中5亿个将赠与简书，以感谢简书对 Fountain 的支持。剩余10亿个将用于社区支持计划，所得资金将用于 Fountain 的开发、运营和市场。

增发分配

基于内容社区的基本特点——用户不断创造新的有价值的内容分享给全体用户，因此整个社区中的价值是在不断增长的，所以我们认为完全通缩或者总量恒定的 Token 经济体系并不适用于这么一个快速增长、鼓励内容生产和消费的社区，因此我们将每日增发100万个 FTN 用以生态激励，首年增发率约为12%，随后逐年降低，趋近于0。每年增发的 FTN 中的85%将基于 PoC ( Proof of Contribution ) 的共识机制用于社区奖励，10%将基于 DPoS 的共识机制用于奖励区块生产，剩余5%转为基金会预留金以保障基金会的可持续发展。为减少投机行为，所有 FTN 的奖励，将可能全部以 FP 的形式给予用户。

PoC机制

用于社区用户贡献证明的 PoC ( Proof of Contribution ) 机制的设计是极为重要的。只有有效地奖励所有社区用户日常的劳动贡献，整个生态才能得到正确地激励，生态也就会不断朝着增长的方向发展。所有持币者也将随着生态的发展，而得到好的收益回报。我们必须明确社区用户有效的贡献方式，并基于这些贡献方式设计 FTN 的奖励。

FP

我们将鼓励 FTN 的长期持有者，因为 FTN 的长期持有意味着持有者对生态的真正参与，他们会基于 Fountain 的长期可持续发展进行投票。而短期持币者会借机低买高卖进行投机行为，并不能对生态的发展做出有效贡献，他们的行为和意志也必不能和 Fountain 的愿景一致。有鉴于此，我们设计了 FP ( Fountain Power )。用户随时可以将 FTN 以1:1的比例兑换成 FP。但当用户选择将 FP 兑换成 FTN 时，FTN 总额即被分成等额的13份，每周兑换1份，13周兑换完成。FP 无法流通，必须兑换为 FTN 后才可以流通。

FP 是 Fountain 的权利凭证。持有 FP 就像是成为了 Fountain 的公民，为生态的繁荣和治理履行义务，同时享有正当的权利。FP 是整个 PoC 运转的核心，PoC 机制的设计基于一FP一票的原则，持有 FP 数量越多的用户对 PoC 奖励池的分配也发挥越大的影响力。因为持有FP的用户的积极投票是整个生态运转的保证，所以每年增发的15%，将奖励给 FP 持有者，鼓励用户将 FTN 兑换成 FP 参与投票。每个 FP 持有者所得到的奖励取决于他们所持有的 FP 占所有用户所持有的 FP 总量的比例。

内容贡献

内容是 Fountain 中最重要的价值，内容的作者理应得到奖励。用户给内容的投票即是对内容的策展，也是给内容增值的过程，所以投票者也应当获得奖励。内容贡献的奖励主要围绕作者的创作 ( Creation ) 贡献和读者的策展 ( Curation ) 贡献来设计。每年增发 FTN 中的55%将用来作为这部分的奖励池。

1.投票权重

作者发表内容，读者阅读内容并产生比如点赞或点踩的投票行为，而每一位读者持有的FP不同，产生的投票权重也就不同。我们取统计周期（即一天）内用户i进行投票的总次数为，那么分配到每一次点赞或点踩上的权重为：其中是用户 i 所拥有的 FP 总数（如果在一天内用户的 FP 数发生变化，则以最后的FP数为准）；D 是准备金；是用户 i 当日所有投票次数。与 Steem 不同的是，Fountain 上的内容是可以被永远投票的。这意味着一篇十年前的小说，在今天依然可以被用户投票，并得到奖励。

2.内容热度值

在计算出每次投票的权重后，我们便可根据读者们为每篇内容投票的情况，计算出内容的热度值。我们认为无论是赞还是踩，只是代表了不同用户的价值观，本身并没有对错，因此都应当被视作投票行为。内容热度值计算方式：

这里是进行点赞或点踩的用户Wi的投票权重，like是所有点赞的人的投票权重的总和，dislike是所有点踩的人的投票权重的总和。我们认为评论即内容，同时文章评论的热度又是文章热度的一种体现。所以每篇内容的最终热度值将加入子评论的投票热度值进行计算：

其中A是内容本身的投票热度值，而后面的求和部分是对子评论的投票热度值进行求和。a是子评论的权重参数，目前拟定为0.5。

3.内容奖励分配

由于一般情况下，中等热度的文章居多，热度特别高和热度特别低的文章都相对较少，接近 Beta 分布，如下图：

这里横轴代表热度值，纵轴代表文章数。将热度平均值 1/e 以下（即红色部分）定义为尾部内容。并对其权重进行调整：将尾部内容根据热度值从高到底排序，根据齐夫定律，取尾部内容中的最大热度值除以排序序号，作为新的权重。这样可以最大限度地降低尾部的灌水内容所占权重，同时保留一定的收益。根据上面所说的规则，现在一篇内容的权重为：

运营贡献

除却内容贡献外，基于运营的贡献也是非常重要的。我们将内容社区应用运营工作中有基础价值的且有群众基础的社区治理贡献和介绍推广贡献，列入奖励范围。每年增发 FTN 中的15%将用来作为这部分的奖励池。

1.社区治理奖励

对内容社区应用来说，围绕违规内容和违规用户行为的治理是非常重要的（例如抄袭他人的作品）。对应用官方来说，这块的运营工作是十分繁重的，同时又让用户感觉不到公正。因此我们鼓励社区用户参与公共事务并给予 FTN 奖励，这即减轻了应用官方的工作量，又让用户有了参与感且整个过程公开透明。提案人、评判人参与社区治理与建设，将采用如下流程：·质押：提案人质押一定量的FP以提交社区治理提案。·判定：提案是否通过、判罚是否准确、提案人是否合规等。·解押：若判定通过，质押标的被解押返还；若不通过，则收入社区贡献者配额池。·收益：解押的同时，提案人将从社区贡献者配额池中获取额外奖励。

由于每日的参与者数量及质押额都是动态变化的，而贡献者配额池的增发额是固定不变的，为解决这个问题，我们设计了如下机制：·若所有参与人质押额小于等于当日贡献者配额池增发额，则在参与人获得与各自质押的FP 相等额度的奖励后，池中剩余增发部分转入次日贡献者配额池，直至发完为止。·若所有参与人质押额大于当日贡献者配额池增发额，则以各个参与者质押总额占当日全部参与者质押总额之比作为权重，等比分配，不足部分自动作为次日质押。·每个参与者次日的质押总额＝今日质押总额－今日已得分配额＋次日新增质押总额。

2.介绍人奖励

社区的发展离不开全体参与者的共同建设，而社区价值核心价值的体现就是优秀内容的数量。因此，我们鼓励全体参与者为社区引入更多的优秀作者。作为被介绍人的引路者，介绍人须借给被介绍人初始准备金，若介绍人账户剩余 FP 不足以借为准备金，则该介绍关系自动取消。与基金会借出准备金具有时限性这点不同，介绍人借出的准备金并没有必须偿还的时限。作为奖励，介绍人可以从社区贡献者配额池中，最高获得与借出的准备金等额的奖励。恶意邀请僵尸用户以领取介绍人奖励的行为是我们所要极力避免的。为了抑制这种行为，我们将以被介绍人所创作内容的最终热度值作为衡量标准，并进行分配：·在介绍人收益达到借出的准备金等额的奖励以前，以其所推介的被介绍人的内容通过PoC 机制计算得的权重的总和，作为介绍人的权重，对社区贡献者配额池中的新增 FP 进行平分。·在介绍人收益达到借出的准备金等额的奖励后，则该介绍人不再参与介绍人增发配额的分配，且当次分配中超过借出准备金额度部分自动转入次日贡献者配额池。·若当日社区贡献者配额池内全部介绍人均已全部领取，但贡献者配额池仍有剩余，则剩余部分将自动转入下一日的贡献者配额池，直至被分配完毕。

用户注册与准备金

为应对针对奖励池的女巫攻击，目前比较常见的抑制方法是：·较高的注册认证门槛;·在受到社区处罚后，参与内容发布时，必须质押部分 FP;·设置准备金制度（即总财富值相同情况下，注册账号越多，占用的准备金越多，从而使得可用的财富值越小）。对于以上三种方式，Fountain 将全部采用，以有效抵御女巫攻击。目前每个用户的准备金将设置为10个 FP。为了提供更加友好的用户体验，在正式上线后，新用户注册时将获得由基金会借出的10个 FP 作为初始储备金。一段时间后这笔储备金将被收回，新用户可以利用这段时间参与社区交互，来获得足够的奖励以承担未来的储备金。

技术方案

1.生态架构

Fountain 的生态架构，可以分为四层，即链层、行业协议层、社区协议层和 DApp：

链层

位于整个系统最底层的链层，可以在现有成熟公链如以太坊或 EOS 的基础上进行二次开发来实现。在必要的时候，再转向 Fountain 的自有公链。链层提供了整个 Fountain 所需的基础功能，是 Fountain 可以正常运行的土壤。由于 Fountain 和其它区块链项目不同，它是有实际业务对应的，用户交互也不仅仅是交易转账，还包括大量社区交互行为，因此对于链的吞吐能力与处理速度都有一定的要求，且记账所需的燃料费也希望趋向于零。由于 Fountain 的定位，是内容行业的行业链，其上未来可能会不止一个内容社区，以及各个社区的大量用户，将会面临包括行业规则调整、社区规则调整、社区内仲裁等等各类不同层次与影响范围的活动，所以在底层链的选择上，我们将采取一种联盟链与公链的混合方案。内容行业的各社区将构成一个联盟链，通过 DAO 的形式来决定行业链上的行业规则是否进行调整，而在各社区内也将建立类似 DAO 的组织形态，用来决定各社区自身的发展。这样的组织结构将有利于行业链的生态形成与演化，同时又能保证行业与社区之间不会出现彼此冲突。在同一套行业规则下，不同的社区可以拥有彼此不同的社区规则。规则的设定是由行业同盟或社区管理组来建立，而一旦建立后，所有用户都在同一个社区的同一套规则中进行互动。从技术上说，我们会在公链的基础上，引入联盟链的架构，作为公链之上的一种追加结构。新联盟用户将通过联盟已有成员的投票来决定是否允许其加入联盟。而联盟的决议也将通过环签名等手段来进行确认与保护，并在必要的时候对整个 Fountain 的相关参数设置或者智能合约进行调整。

协议层

协议层分为行业协议与社区协议两部分，分别对应了整个内容行业的基础规则与相关服务，以及社区特有的规则与服务。行业协议是全行业都必须遵守的一套规则，包含一组智能合约与相应的基础服务，而社区协议则是内容行业中某个特定内容社区所专有的。从形式上说，它们都是建立在底层链基础上的一组智能合约，以及相应的 DApp 可用的网络服务与协议。不同的 DApp 根据所在社区不同，调用不同的智能合约与网络服务。

DApp

每个社区都会有自己的 DApp，用于将社区中的内容呈现给用户。它是整个生态的展示与交互界面。DApp 可以是社区自己开发的官方版，也可以是第三方开发的私有版，只要遵守行业与社区的两套协议，就能调用相关网络服务与智能合约。我们可以借用软件架构中的 MVP 架构来表达底层链、两个协议层与各 DApp 之间的关系：

基础服务

在 Fountain 上，有一些基础服务是现在与未来所有内容行业都会用到的，比如内容的链上存储、内容寻址、链上 KYC 解决方案、Markdown 和富文本编辑器解决方案等等。其中，Fountain 主要使用的一项基础服务就是内容寻址，其本质上是一组智能合约，通过一组链上可识别的 HASH 表示“转译”为互联网上通用的 URI 地址，从而让 DApp 可以获取指定的资源。这是一种链-网结合的方案，对于链上无法处理或不便于处理的内容放到传统互联网上进行处理，而链上通过调用互联网服务的形式进行资源获取。这类服务的实现方式有多重，可以是服务器通过 DApp 接入到链上，通过接受特定的智能合约 Event 事件来触发相应，也可以是 IPNS 这种分布式域名解析服务。

2.准入制的必要性

包括内容社区生态在内的各网上生态系统要能健康发展，依赖于社区规则与交互界面（ App 或 DApp ）的健康发展。在内容社区中，破坏这种健康发展的主要手法，有以下这些：·不遵守协议规范的第三方 App / DApp 对生态进行破坏；·利用机器人等手段伪造多个账号破坏社区生态；·利用社区规则漏洞，进行表面合理但目的在于个人利益最大化的交互行为。……举个例子：第三方 DApp 可以通过发布违规内容来扰乱整个经济系统。违规内容有很多可能性，比如说大量的“抄袭”或者“暴恐”内容。这样的行为会对整个 Fountain 生态带来极其负面的影响。因此，我们的解决方案是 DApp 的准入机制：有行业联盟或社区管理组来判断一个第三方 DApp 是否具有准入资质，如果具备准入资质，则给与它一个特定的令牌 Token 。而在调用智能合约或者别的网络服务的时候，需要提供该 Token 的 DApp 才有资格调用该 DApp，比如如下简化的智能合约（ Solidity ）：

contract TestContract { address public owner; mapping (bytes => bool) public dapps; modifier onlyOwner () { require(owner == msg.sender); _; } modifier onlyDApp (bytes32 token) { token = keccak256(token); bool got = dapps[token]; require(!!got); _; } constructor () public { owner = msg.sender; } function addDApp (bytes32 token) public onlyOwner { token = keccak256(token); bool got = dapps[token]; if (!!got) return; dapps[token] = true; } function removeDApp (bytes32 token) public onlyOwner { token = keccak256(token); bool got = dapps[token]; if (!got) return; dapps[token] = false; } function dosomething (bytes32 token, address from, address to, uint amount) public onlyDApp(token) { ... }}在上述这段代码中，我们可以通过特定账号为整个社区添加允许的 DApp 准入 Token，且可以在需要的时候将一个 Token 移除，从而来控制被保护的智能合约函数。事实上，这样的方式也可以用来做更复杂的权限管理。对于已经通过第三方 DApp 上链的内容，由于其内容未必保存在简书服务器上，而只是将 URL 放入了链，从而可以通过内容寻址服务找到该特定内容的地址，从而进行展示（在官方 DApp 上当然会做过滤，但在第三方 DApp 上则不会有过滤）。对于这种情况，一个是内容寻址服务中将会把相关条目删除（以 IPFS 及其背后的 Kad 与 BitSwap 来说，就是将特定地址对应的 route 与 storage 全部清空），另一方面是对链上相关条目进行标记，标记其为违规内容，从而确保在官方以及遵守官方协议的 DApp 上不会展示内容相关条目。

3.去中心化的付费阅读平台

传统中心化的付费阅读平台的劣势是毫无疑问的，大量的收益被平台所获得。原创作者理应获得更高的收益。付费阅读的关键，就是要记录和验证指定用户对指定文章是否进行过付费购买。我们可以在区块链中记录购买信息，并在有需要的时候进行检索验证，从而实现付费阅读。具体来说，当用户对一篇文章进行购买时，我们需要将购买记录记录在链上。而当用户要阅读一篇付费文章时，内容寻址服务到文章存储服务器上进行内容索取，此时文章存储服务器会到链上查询当前用户是否购买了指定文章，如果购买过，则提供文章，否则不提供。简单的这类智能合约的大致流程可以写为（Solidity）：contract MasterPiece { address public butler; mapping (address => uint) prices; mapping (address => mapping (address => bool)) public bills; constructor () public { butler = msg.sender; } modifier onlyButler () { require(butler == msg.sender); _; } function setPrice (address article, uint price) public onlyButler { prices[article] = price; } function buy (address article) public payable return (bool) { uint price = prices[article]; if (msg.value < price) { msg.sender.send(msg.value); return false; } bills[msg.sender][article] = true; return true; } function check (address user, address article) public view return (bool) { return bills[user][article]; }}在初始阶段，我们会使用云服务器来作为文章的存储服务提供方，未来会考虑转用类似 IPFS 这类分布式文件存储服务，并设置一个付费阅读秘钥分发系统，将文章密文保存在分布式文件系统中，而将解密用的秘钥通过这个秘钥分发系统来管理与分发，从而实现付费阅读。

4.去中心化的 IP 投资平台

在内容创作领域，我们经常遇到的一个问题，就是作者有一个很不错的构思，但迫于生活压力而不得不放弃这篇内容的创作而转做其它。一个更健康的去中心化的 IP 投资平台对作者来说是很有有价值的。由作者发布作品项目，包括完成作品的时间规划，作品完成后的收益分配规则，而由读者在作品完成之前，先行为作品付费，并在作品完成后的一段时间内完成作品收益的自动分配。传统的IP投资平台，具备大量信息的不公开透明，应用了区块链账本的IP投资平台，将让更广大的群众将更有信心参与其中。一份这样的智能合约，其大致形式为（Solidity）：

contract WritingProcess { address public butler; mapping (address => WritingProgram) public programs; event NewProg (address author, address article, uint stocks, uint price); struct WritingProgram { address author; address article; uint public total; uint left; uint public price; uint stockcoinpool; uint public coinpool; mapping (address => uint) stocks; constructor (address _author, address _article, uint totalstock, uint stockprice) public { author = _author; article = _article; total = totalstock; left = totalstock; price = stockprice; coinpool = 0; stockcoinpool = 0; } function buy (address buyer, uint stock) public return (bool) { if (left < stock) return false; uint s = stocks[buyer]; s += stock; stocks[buyer] = s; left -= stock; stockcoinpool += stock * price; return true; } function income (uint coin) public { coinpool += coin; } function draw (address a, uint amount) public { if (a != author) return; if (amount > stockcoinpool) return; a.transfer(amount); stockcoinpool -= amount; } function sharebonus (address user) public { uint s = stocks[user]; if (s < 1) return; uint p = coinpool * s / (total - left); user.transfer(p); coinpool -= p; stocks[user] = 0; left += s; } } constructor () { butler = msg.sender; } modifier checkProg (address prog) { WritingProgram p = programs[prog]; require(!p); _; } modifier checkProgAndPayBack (address prog, uint coin) { WritingProgram p = programs[prog]; if (!p && coin > 0) msg.sender.send(msg.value); require(p); _; } function publish (address user, address prog, uint total, uint price) public checkProg(prog) { p = new WritingProgram(user, prog, total, price); programs[prog] = p; emit NewProg(user, prog, total, price); } function buyStock (address prog) public payable checkProgAndPayBack(prog, msg.value) { WritingProgram p = programs[prog]; uint s = msg.value / p.price; p.buy(msg.sender, s); } function rewardProg (address prog) public payable checkProgAndPayBack(prog, msg.value) { WritingProgram p = programs[prog]; p.income(msg.value); } function shareProgBonus (address prog) public checkProgAndPayBack(prog, 0) { WritingProgram p = programs[prog]; p.sharebonus(msg.sender); }}以上是我们的一些技术方案探讨，我们将根据项目实际进展进行调整和细化。对 Fountain 来说，能迅速收获千万用户是让人兴奋的事情。同时这也意味着对技术和架构有着更务实的要求。

发展路线

Fountain 的生态架构，可以分为四层，即链层、行业协议层、社区协议层和 DApp：

由于 Fountain 的初衷是利用 Token 奖励来构建有价值的内容社区，进而整体方案设计主要着重于 PoC 机制，为了最快速对 PoC 机制的测试和后续迭代，初期 Fountain 可以基于现有成熟的公链如以太坊或 EOS 进行开发。Fountain 的发展预期分为三个阶段：

Alpha阶段

本阶段的核心目标，是实现包括 Fountain 代币系统、账号系统、内容寻址与获取、基于内容的交互激励在内的核心功能。在本阶段中，我们将建立一套链上地址到内容的寻址系统，并建立起用户信息与交互收益的完整记录系统。同时将与合作方一同建立一套基于链上交互行为的收益核算系统，初步实现 PoC 机制及其它云上配套服务，并进行相关记录与测试，以完善相关社区设定与配置，为未来的拓展做好准备。本阶段完成时，链上与云上的基础服务和经济激励模型将基本完成，可进行初步测试。同时，我们也会开始着手为未来的行业链定制一套完整的公链体系（Fountain 链），在已有公链如以太坊、EOS等的基础上，针对行业特性如海量用户、高频交互等进行定制。

Beta阶段

在 Alpha 阶段的基础上，我们会逐步将上一阶段中在云端完成的工作逐步转移到链上，并在链层增强行业链的联盟功能，为更多社区平台的接入以及整个内容行业的自治做好准备。在协议层我们将进一步完善仲裁系统，实现基于通道的 KYC 服务等；在社区层与应用层我们则会完善介绍人系统以及相关社区治理模型，从而将 Fountain 的既定功能逐步实现并完善。该阶段中，会开始逐步从合作方将用户数据、虚拟资产数据、社交数据和内容数据导入到测试链与 Fountain 链上，并允许这些内测用户在 Fountain 链上进行全规则全功能的测试。我们会根据每天的试运行结果，将系统中的各参数进行优化，并最终确定一组参数用于日后的正式运行。在行业公链方面，我们准备在本阶段内完成主要定制化模块的开发与调试，为进入下一阶段做好准备。