Trinity-NEO加多一个辅助轮，状态通道链下方案

BLOCKSPACE

可信任的价值互联网，从这里解锁

Trinity

基于NEO的链下拓容方案

项目介绍

1

摘要

一句话概括

通过状态通道方案来达到NEO链上资产的即时支付、低交易费用、可扩展以及隐私保护，微支付作为切入点，辅佐承载Dapp为长远目标。

定位

基于NEO的链下拓容方案，NEO版本的闪电网络， 用于NEP-5标准代币的区块链转账， 包含协议分层、服务可插拔、定制等方案。

背景

链下拓容方案在微支付领域的可行性

落地商业应用对性能的要求

小结

常规视角来看比特币的闪电网络、以太的雷电时，第一印象是后者辅佐前者，要看前者脸色，Trinity也一样，我们当然会关心NEO对它是否认可，双方是否能有配合，或者技术层面的对接等等，但这里有一个区块链世界和传统以及互联网世界很大的不同之处，即去权威的价值观，任何一条公链无法阻止外来开发者对其改进对愿望，以太坊社区最初也不认可或明面支持雷电，甚至认为雷电不应该众筹，但毫不影响雷电自身稳定踏实的开发进展以及生态拓建；同样，Trinity作为技术性要求高的项目，可能更多需要考虑自身能给NEO带来多少影响。

亮点

殊途同归，和竞品平行竞争

小结

状态通道、链下拓容、余额证明等并非新词，就像预言机、侧链等方案，很难说谁是始祖，谁现在就已经做到最好了，从白皮书来看，Trinity在思路和逻辑上和雷电有相似之处，但由于两者站队不同，其实差别很大，NEO现有性能不差、且自身的链上解决方案等方面还预留了不小的成长空间，假设把Trinity类比为提速双管齐下或多管齐下的某一只轮子。对Trinity的必要性和需求随着NEO生态上小额支付场景需求提升。

不排除今后会有打着类似的跟风类项目出现，但低延迟、可拓展、低交易费中任何一个环节的解决都并非易事，雷电本身都存在一定的失败可能性。

代币功能

统一的网络结算资产

激励环节

增值服务

企业定制服务费

社区激励

小结

代币流形成合理的闭环，在白皮书中虽然没有一一列举，但小额支付场景由于高频和低手续费的硬性要求，其实比较适合IOT领域，物物之间产生的庞大数据量、实时性来说，链上计算是不现实的，基于NEO的物联网领域项目，和Trinity契合度将很高。

2

逻辑

资产证明

状态通道

小结

先举一个可能不恰当的类比，应用型的白皮书基本在讲经济学故事，协议类的白皮书讲数学故事，基建类的白皮书则要讲科学故事。Trinity的技术实现部分，我们重点看数学逻辑是否自洽即可。

在白皮书中技术实现部分提到许多概念，其中资产抵押、支付通道中的智能合约代币，通道生命周期几个概念组合来看。均是为了保证双方不随意退出，如何确定Trinity链和跟主链拥有一样的约束力。由于要满足通道容量等于双方参与者存款总和，所以需要满足以下状态：

参与者余额=参与者押金+收到的交易金额-付出的交易金额。

锁定余额=锁定未交易的总和。

Bl=Σk=0 n−1Tp

此外，白皮书目前是初步的披露版。除了思路和设计，具体的代码和编程实现以及和NEO的适配等将涉及到更多环节。

团队成员

CEO是前小蚁海外经理，小蚁转NEO前离开，是Fourier联合创始人，有较强强的PR经验以及合作资源。两位合伙人中张广锋有过基于区块链技术的票据系统开发经验，易锋平由于从业背景，有区块链项目渠道拓展经验。

顾问团

数字货币基金Badwater Capital联合创始人徐敬程、本体首席战略官季宙栋，NKN联合创始人李彦博。

小结

项目的运营团队经验丰富，由于整体属技术性要求很强的类型，落地的难点将更多落在开发成员实力和磨合上，目前披露的核心开发成员中，李杨有涉及过过多资产钱包的开发，除此之外，团队总人数20，开发人员超过10名。

路线规划

官网和白皮书暂无roadmap，开发进度方面，1月底进行1对1状态通道的演示。后续阶段的工作重心在NEO适配，以及多对多状态通道解决方案的突破上。

社区资料

官网：

https://trinity.tech/

白皮书：

https://trinity.tech/file/WhitePaperDraft.pdf

电报：

https://t.me/TrinityStateChannels

博客：

https://trinity.tech/index.html?language=cn

twitter：

https://twitter.com/TrinityProtocol

facebook：

https://www.facebook.com/eximchain/

github：

https://github.com/trinity-project