区块链如何从协议层开始变得更有用

为了帮助抵抗审查、不可变和无许可的区块链获得广泛的市场接受，需要做很多改变。从基本协议到最终用户界面，生态系统的每一层都需要变得更加可用。为了实现有意义的采用，这些层必须利用区块链的独特属性。那么如果界面正在审查，使用一个抵制审查的区块链有什么意义呢？

今天是系列文章的第一篇，详细介绍了不同区块链层的区块链可用性（我们完全按照OSI建立了模型）。在这里，我们将重点讨论基本协议，并在后续的文章中继续讨论。

抽象层

互联网遵循OSI模式：

一种概念模型，它描述和规范电信或计算系统的通信功能，而不考虑其底层的内部结构和技术。它的目标是使用标准协议的不同通信系统的互操作性。该模型将通信系统划分为抽象层、服务于抽象层上面的层，服务于抽象层下面的层。这些层作为一种隔离机制存在，在最顶层工作的人不应该关心它下面发生了什么，反之亦然;这是完全的抽象。这是一种基础性的现代发展实践。在过去，机器人手臂的开发者必须知道每个硬件设备之间是如何通信的。但是现在有了通用的api，所以开发人员不需要担心注册格式、I2C地址等，从而允许代码重用、更快的开发等等。尽管以较低的性能为代价，但开发速度远远超过了这一点。区块链也是如此。

在栈的较低层仔细的设计决策会极大地影响上层的可用性。如果没有稳固的基础，顶面的任何东西都是摇摇欲坠的。如果密码系统坏了，用户不能信任协议。

分类可以用多种方式构建，这些层次反映了当前用户体验的心理模型，请联系出建议。给你一些灵感：Multicoin的Web3栈，一个来自过去的Vitalik post，Web3 FoundaTIon， Evan Schwartz的5 Layed Interledger架构，区块链应用栈和7层金融密码学。

图：区块链层的可用性

在确定区块链的可用性之前，我们需要了解协议的目标。如果一个协议只打算用于跟踪和管理银行隔夜市场的资产，那么该协议可以被允许或联合使用。然而，如果协议是为不可替代资产的无许可基础设施设计的，那么对可用性的要求就大不相同了（BFT共识，等等）

人们经常说，交易的低终结时间、高交易吞吐量和低交易成本对于任何区块链都是必不可少的，但实际上，它们独立于可用性，这取决于协议的目标是什么。对于共识规则也是如此，如果允许网络或联合网络，区块链不需要具有拜占庭式的容错能力。考虑到这一点，我们一直小心翼翼地只讨论能够超越这些不同设计目标通用的可用性属性。

从基础做起

从底层开始，我们可以确保构建在顶层的层能够继承已经本地集成到基本协议中的可用性特性。这里构建的内容会同时影响开发人员和最终用户。

协议设计人员应该采取哪些步骤对其他人产生最积极的下层影响？

协议应该包括的特性

特性

· SPV证明或轻量级客户机： 协议的所有用户不太可能使用完整的节点与区块链进行交互，更常见的是使用托管节点服务。它们工作得很好，但代表着一个单一的失败点，审查制度和缺乏隐私。使用SPV证明或轻量级客户机，用户可以自己验证和发送事务，而不必信任其他人。如果这些轻量级客户端只占用很少的资源，这就给了用户更多的自主权。Coda协议是这个领域的领导者。

· 基于帐户的建模： 尽管UTXO模型有许多好处，但是基于帐户的建模对用户更友好，因为只有一个规范帐户，这使得密钥管理更加简单。更妙的是，如果一个人可以向该帐户注册多个密钥对，那么如果他们丢失了一个密钥对，那么还有其他可用的密钥对。Near协议目前正致力于此。

· Fork友好性： 一些协议认为不应该有Fork，并且内置了一些机制，使Fork变得困难。人们总是会找到一种方法来派生协议，因此协议设计者应该认识到恶意行为者/有争议的硬分叉，并内置工具来标记分叉和防止双重支出。

· 分层确定性钱包： 也称为高清钱包，它允许一个种子或助记短语生成无限数量的公钥。因此，用户不必存储所有的私钥，只需存储种子即可。

· 共识： Fischer Lynch Paterson （FLP）指出，一个确定性系统最多可以有两个异步共识以下三个属性：安全（结果是有效的和相同的节点），活性（节点不失败总是产生一个结果），和容错（系统可以在任何点）存活节点的失败。没有一种共识机制可以拥有所有的特性，任何互联网上的分布式共识系统都必须牺牲其中的一个特性。因此，在为协议选择共识机制时，设计人员必须确定他们看重什么以及它如何影响用户体验。来自Stellar的一些设计灵感。

· Dust Handling：由于交易费用大于UTXO的价值，所以代币不能再被所有者使用。从用户的角度来看，这是不理想的，因为他们已经被剥夺资金，如果有一个聪明的方法来避免这种情况，就更好了。

网络维护人员的特性

全节点激励： 用户运行全节点应该是有原因的，不管是因为网络被许可，还是因为存在加密货币的经济激励，用户必须这样做。如果没有完整的节点，网络的安全性和支持就会降低。奖励应该涵盖协议的最重要特征，在比特币的Nakamoto共识中，只有在最长链上开采比特币的矿商才能获得奖励。但由于没有推广区块的动机，这不幸导致了自私的开采。或许鼓励块中继的激励措施可以解决这个问题，但这只是激励措施的冰山一角。

实现细节：有许多方法可以实现协议的规范，开发人员必须仔细检查角落的情况，以防止意外的攻击和未知的膨胀。

协议中的额外协议特性

这些特性也应该集成到区块链协议中，以提高其可用性。然而，它们可以在几个级别上实现，它们应该是协议本地的，并且可能是协商共识规则的一部分，还是应该存在于智能合约层甚至链外？一些协议已经对此采取了立场，但是我们不会让您卷入这场争论，相反，我们将讨论为什么这些特定的特性在堆栈的任何部分都具有强大的功能。

· 费用委托/元事务： 对于最终用户，他们甚至需要知道他们正在使用区块链吗？除非交易费用委托给第三方，否则用户永远都知道他们在使用区块链，必须购买代币，这就增加了一层摩擦。以太坊正在开发基于智能合约的费用委托（与正常交易相比，它的GAS成本是普通交易的2 - 3倍，dApp必须特别支持它），而其他协议（Stellar和VeChain）则是原生协议。尽管如此，现在用户可以在协议之上使用资产，甚至不知道是什么在驱动它。

· 人类可读的地址：还记得你输入“O”而不是“0”，然后烧了一堆钱吗？EOS本身就有这个特性（注意它是强制性的，并且需要花费代币来注册，这会降低可用性），以太坊使用ENS，这是一种智能合约。现在这种情况不会再发生了。

· 本机多签名： 对于协议来说，拥有一个本机多签名或智能合约是最重要的。它们可以在脚本（BTC P2SH）或密码门限签名中实现。试着找出一个协议不应该只有一个的原因。

· GAS市场-区块链领域未来： 交易费用是第一价格拍卖，无论在理论还是实践上都容易导致定价不完善和参与者之间的博弈。为了缓解这一问题，人们提出了几种不同的模型，比如改变拍卖方式，或引入GAS市场。这些更改应该是协议的一部分还是存在于合约层？

· 本机交换： 当特性以本机方式实现到核心协议和协商共识时，由于代码是作为客户机的一部分编写的，而不是使用更高级的智能合约语言，因此特性通常更具有性能。Stellar有一个本地分布式交换器，由于协议的资产特性，这是有意义的，但是请注意，这个特性不应该用于非资产的协议。

复杂性转移

协议本身需要一些特性，比如多签名（在我看来，不同意也没关系）。但是它位于哪一层：基础层、智能合约层或第2层，以及特定的实现极大地改变了用户体验，并将复杂性转移到不同的层和各方。是否希望使基本协议非常的轻量级？或者它应该整合所有东西？我们可以假设用户对交互协议没有问题，还是我们应该假设行为是不可取的？这是一个特征还是必须具备的？这些是任何协议设计者必须问自己的一些基本问题，他们必须认识到复杂性将永远存在。谁应该与复杂性打交道，谁应该承担责任？

平衡核心开发人员和社区

为了合法地消除风险，协议不能拥有整个生态系统。如果开发协议的公司运行几乎所有的节点，开发所有的辅助组件，等等，那么很难不说协议是集中的。公司可能会被追究法律责任。

因此，外部开发是必要的，但如何平衡他们的贡献与项目的愿景也同样重要？一个项目必须有一个具体的叙述，以确保社区的所有发展都有一个指路明灯。那么到底是安全还是信任呢？是公司的钱包更容易信任，还是外部的钱包更容易信任？这些线路不容易走。

展望未来

在决定每个层实现哪些可用性特性时，我们需要做的是要认识到协议的设计目标是什么。