公众号：合约大陆欧米社区 今天
在保持记录的过程中，许多行业都处于下一轮技术革命的边缘。比特币大放异彩十年后，我们看到许多人受到了用钱案例之外的技术带来的一些好处的启发：
- 可验证的，不变的记录可降低风险
- 共享实时数据，提高效率
- 简化跨信任边界的交易支持的流程
但是，许多人仍不确定是否可以实现这些好处，部分原因是在最初十年中采用这些技术的速度较慢。
在本文中，我将阐述为什么在数字资产的我们相信分布式分类帐和智能合约是资产和流程数字化的下一个重要步骤。我还将提供一个解释，说明为什么采用这种方法需要很长时间才能获得动力，围绕资产数字化的一些常见误解，以及我们如何解决DAML生态系统中的这些障碍。
记录保存的演变
“记录保存”可能没有流行的“区块链”，“智能合约”或“令牌化”功能，但这就是所有这些技术的含义。合同，法律和所有权的记录以及更改这些记录的过程是社会和行业的基础。因此，用于记录保存的技术正在不断发展，每一项新的创新都试图解决以前存在的问题。
几千年来一直存在着物理所有权记录，无论是形式的纸质不记名票据（如期票或现金），还是集中式记录（如土地登记簿）。他们解决了一个基本问题，即以一种商定的，法律上可执行的方式来确定谁拥有什么。
不幸的是，这些基于纸张的记录和过程速度慢，昂贵且容易出错。甚至在计算机问世之前，就已经开发出专用的机器来辅助保持关键记录准确的任务。20世纪下半叶，计算机的出现极大地提高了保存和更新记录的效率，从而导致大多数资产类别的广泛数字化，包括现金、股票、债券、国库券和各种凭证。
此后不久便进行了有效的分发和通信，首先是通过点对点数字通信渠道，然后是互联网。
随之而来的是数据处理和通信效率的提高以及数据分配的规模，带来了最初的问题，即无法在给定的时间点明确地确定资产的所有权又回到了最前沿。现在，每条记录都可以通过一个松散的计算机网络进行多次复制，并且记录更改可以通过网络分多个步骤进行。为了使所有副本保持同步，需要进行复杂且昂贵的对帐，而错误是司空见惯的事情，这导致在纠纷解决和异常处理上的更多支出。
计算机革命并未改变机构在保存记录方面的作用。大多数记录，无论是银行帐户，保险单，健康记录还是土地所有权，都具有由单个或少量实体控制的“主副本”。根据业务需要（通常是法律），这些控制方必须保留此数据，这些数据代表其客户对这些数字资产的合法所有权的准确性和安全性。
适当实施的分布式分类帐可以解决这些问题，方法是允许更多的方访问主副本，并将受信任实体的权限编码为可验证的操作。这消除了和解的需要，并减少了控制机构所需的总信任。
那么，为什么我们还没有看到针对广泛种类的资产迅速广泛地采用令牌化呢？
我相信有几个主要原因，但也可以通过改变思维方式和最新技术来克服所有这些原因。改变的时机已经成熟。
代币化错过了重点
令牌是数字载体工具。令牌应代表可赎回的证券声明，并从该声明中得出其价值。持有令牌等同于拥有对该资产的所有权，并且所有权可以自由转让。在这些方面，代币模仿现金：
- 上述[联邦储备]票据应为美国的义务，应根据需要在美国财政部，华盛顿市，哥伦比亚特区或任何美联储银行以合法货币赎回它们。
许多人已经提供了多重签名，作为在令牌（包括我们自己！）之上添加一层法律控制的一种方法，这种方法确实具有一定的吸引力，作为在转移和控制资金过程中的最后一步。但是，法律框架和流程比最终私钥的简单行使要涉及的协调和授权要多得多。这使得多重签名在某些过程中是值得进行的步骤，但未能完全代表大多数企业操作所依据的法律要求。具体来说，多重签名在某些情况下可能适用于不记名资产，但不适用于所有权记录。
实际上，大多数资产都不是承担工具。所有权记录由法律认可的受监管实体保存和控制。依法管理的分类账上的所有权在法律上是可执行的，并且所有权和转让的限制通常适用。资产是从赋予所有者的法律上可执行的权利中获得价值的。
房地产是资产的一个很好的例子，也是令牌的坏用例。
房地产不是承载工具。如果我丢了房子的钥匙，就不会失去所有权。同样，如果我挥舞着纸质土地所有权时转向别人的财产并要求没收，我可能会因伪造或盗窃而被捕。
房地产所有权由土地注册机构控制，只有土地注册机构的分类帐在法律上可强制执行。在许多地方，对谁可能拥有房地产以及在何种程度上可替代和可转让具有限制。
因此，如果我丢失了房地产令牌的私钥，同样不会失去房屋所有权。法官将当地房主驱逐给伪匿名外国代币持有者似乎是不可想象的。如果该令牌持有者通过法院管辖范围之外的手段（恶意或其他手段）获得控制权，那将尤其令人怀疑。这就引出了一个问题——如果您的目标是“最大程度地分散”这类资产，那么代币持有者会因实施复杂性的费用而获得哪些保护？
购买地块的目的不是要获得土地注册处的录入权，也不是土地所有权可以完全控制从地心到外太空的圆锥体。它赋予了所有者一套非常具体的权利：建造房屋的权利，让陌生人离开土地的权利，分割土地并出售部分土地的权利。前两个令牌不会为您做任何事情。
实际上，对于许多其他类型的“所有权”，例如证券或媒体，该术语用于传达一组权利的概念，这些权利实际上是单独交易的：租赁所有权或土地上的矿产权，股息或投票权。在证券上。在某些领域，这是如此复杂，以至于“所有权”实际上已变得毫无意义。数字版权管理就是其中之一，它显示了数字资产的“所有权”实际上是关于：权利。
为了获得开放或共享记录的好处，我们不能仅将所有权记录为不透明的令牌。相反，无论是集中式还是分散式，我们都必须代表构成我们数字系统所有权的权利。这就是智能合约的用武之地。它们旨在对资产所有权授予所有者的特定权利进行编码，并对围绕这些权利的规则和流程进行编码。
刚性壁架
智能合约规定的规则不能取代法律和法规。实际上，现实世界中的法律，法规和合同通常易于解释。它们的实际含义取决于实践和法律测试案例。
采取行动具有绝对的必然性，并且由无私的节点网络执行的规则并不能反映现实世界的微妙之处。这种僵化也导致巨大的风险，因为合同中意想不到的缺陷是一成不变的。这也不是假设的风险。著名的DAO漏洞是由智能合约中的一个细微错误引起的，并且只能由所有以太坊用户中的大多数更新其节点以同意分叉区块链来解决。
对于大多数业务用例而言，这种刚性是不希望的。相反，大多数智能合约必须是对现实世界中的合约，法律和法规的反映或编码。受合同约束的当事方必须能够通过相互协议来更改，取代或撕毁它，就像他们与真实合同一样。合同规则必须由拥有合同利益和利益的当事方执行，并有明确的解决争端的途径。而那些不在合同之外的人应该没有发言权。
隐私权差
资产发行人和投资者有不同的隐私要求。投资者希望他们的资产和交易尽可能地保密。发行人必须知道谁拥有资产，并有责任确保个人信息的安全。
大多数区块链系统是完全公开的，并在所有参与者之间完全复制。大多数链上的主要隐私保护措施是使用匿名地址来创建相对较弱的匿名形式。
对于投资者而言，假名通常是无效的隐私形式，需要大量的注意。由于所有用户都可以看到所有交易，因此可以推断很多。对于许多企业而言，机密性被破坏以及有关交易信息公开的风险是无法接受的。
对于发行人而言，匿名使得无法满足其有关KYC，反洗钱或数据保护的法律要求。确实，尚不清楚此类系统是否能够遵守GDPR之类的数据保护法规，该法规管理很多种类型的记录，这些记录很可能保存在分布式分类帐中。
换句话说，大多数当前平台提供的（缺乏）隐私不适用于除加密货币以外的所有各方和资产类型，而加密货币是为了其他网络属性而进行此折衷的。但是即使在那儿，许多人都希望获得隐私，但是却很难实现。
区块链不能取代信任
就像保留记录一样，对所有权的信任在整个历史中都得到了极大的发展。以银行业为例，这一切都非常简单。信任关系完全集中，客户必须完全信任其银行。银行客户完全暴露于其银行烧毁，被抢劫或挪用资产的风险。这样的单点故障很容易理解，但风险很高。
这种风险对企业和消费者都有害，因此当今的金融系统已发展成为一个复杂的法律，法规和机构体系，试图保护我们的资产。系统提供的可感知的安全性可以帮助我们的市场平稳有效地运作，从而造福整个社会。但是，它们在一定程度上增加了复杂性和不透明性，使许多人不再完全了解他们暗中或明确信任的人。在2008/2009年金融危机期间，有些人很难学到这一点。
公共区块链的创新在于通过简化信任范围的另一端来简化。信任现在转移到了民主多数——51％。对于加密货币之类的应用程序（所有权利仅涉及记录本身），它非常有效。加密货币用户可以在他们的名字中有一个硬币记录，然后他们可以进行转移。
大多数权利不是那样。在一块土地上盖房的权利与该权利的记录无关。需要一个现实世界的政党来保证和执行这项权利。通常，权利的担保人是受委托保存这些权利的机构。使这些记录的记录民主化几乎没有实现，这就是为什么除了加密货币以外很少有真正分散的应用程序的原因。
智能合约不会取代信任，而是使信任变得明晰透明。一个好的系统以一种使各方都了解他们的权利，义务和风险敞口的方式来编码合同所有参与者之间的信任假设。必须明确了解谁最终负责维持分类帐与现实世界之间的联系。
锁定的风险
开发分布式应用程序在很大程度上类似于几十年前开发大型机应用程序。表面语言和系统内部之间几乎没有抽象。应用程序是为一个基础架构构建的，并永久地与之关联。
但是Gartner预测，到2021年，将需要替换当今90％的平台。认真的企业如何在知道将被锁定在两年内将被取代的技术和基础架构供应商的基础上，如何投入大量资金来更换关键系统？
我们使用的分类帐需要赶上传统的应用程序开发堆栈，这些堆栈在不同层之间提供了清晰的抽象。只有使应用程序在分类账基础结构之间可移植，它们才能适应未来的发展，并降低开发的风险，使之可以被广泛采用。
DAML：用于智能承担风险的智能合约
DAML是数字资产（Digital Asset）对所有这些问题的解答。它是一种高级智能合约语言，旨在为企业及以后的分布式应用程序开发带来空前的生产力。
记录和权利的简洁语言
DAML具有丰富的数据定义语言来描述记录，以及权利方根据这些记录所拥有的内容。例如，下面的一块土地所有权表示法赋予所有者权利，要求对土地进行细分。
templateLandRecord
with
owner : Party
commune : Party
plotId : Text
where
signatory owner, commune
controller owner can
nonconsuming RequestSubdivision
: ContractIdSubdivisionRequest
with
params : SubdivisionParameters
do
create SubdivisionRequestwith
owner
commune
plotId
params
清晰的数据控制带来灵活性
以上合同是土地所有者与其公社之间的合同。如果合同有误，则这些当事方应能够对其进行修改。DAML具有通过签名者进行数据控制的明确概念。所有者和公社可以共同更改所有权记录。
templateLandRecordPlotIdCorrection
with
owner : Party
commune : Party
plotId : Text
correctedPlotId : Text
where
signatory owner, commune
controller commune can
CorrectRecord
: ContractIdLandRecord
with
oldRecordCid : ContractIdLandRecord
do
oldRecord <- fetch oldRecordCid
archive oldRecordCid
assertMsg "Old Record does not match correction"
(oldRecord == LandRecordwith
owner
commune
plotId )
create oldRecord with
plotId = correctedPlotId
使用此附加合同，公社和土地所有者可以决定以完全协议的方式通过双方协议更正记录。不需要计划“升级”或“纠正”合同。明确的数据所有权概念使其可以立即使用。这与公共区块链形成了鲜明的对比，公共区块链应包含专门设计为最小化，理想情况下根本不可修改的无许可智能合约。
隐私而非匿名
DAML分类帐模型精确指定了谁有权查看数据，并遵循一小组原则来导出可见性规则：
- 每当一方看到行动时，都会看到所有后果
- 当事人看到对他们所拥有的合同有任何诉讼
- 除非明确指定为观察员，否则派对一无所获
这些规则可以最大程度地保护隐私，同时确保任何一方最终都能获得分类帐的完全有效视图，并且可以确保所有人都被告知他们所持股份的合同状态。
DAML快速入门指南提供了使用简单交易模型的子交易隐私的强大示例。在DAML中，可以原子交换由两个机构担保的资产，而无需任何一个机构了解到他们所转移的资产已经转移的更多信息。
明确的信任
上面显示的触发土地细分过程的权利不能在账本上强制执行。必须信任公社或上级主管部门，他们会遵守账本上的协议并在处理过程中发挥作用，以决定请求是被接受还是被拒绝。
DAML使这一点非常明确。未经当事人同意，任何一方都不能成为合同的签字人。如果公社在LandRecord上签字，则意味着他们可能是合同中规定的权利下的义务方，并已同意这些条款。合同的签署者是必须信任的那些签署者，以维护所描述的权利并维护总账链接。
基础架构抽象
DAML及其API适用于分布式应用程序，而SQL和ODBC适用于集中式应用程序。数据与逻辑规范，底层存储基础结构以及使用数据的客户端应用程序之间的简洁接口使应用程序无需重新设计即可移植。
与其他智能合约语言和技术堆栈相比，这种抽象使DAML更加易于学习和开发。开发人员不必担心计划要部署到的基础结构的详细机制，而系统级的问题也完全不用担心。通过学习一种语言和一种API，应用程序开发人员可以开发用于本地部署，云和分布式分类帐的应用程序。
它还降低了风险并加快了分布式应用程序的开发。可以开发应用程序而不必担心哪种基础结构适合当前和将来的需求。它们可以在与生产部署完全不同的基础结构上进行开发和原型化。DAML支持广泛的基础架构，从本地数据库支持的解决方案到云托管的分类帐，一直到DAML分类帐模型真正的完全公开的区块链。
图片来源：Randall Munroe。编辑。 CC-BY 2.5。原始图像。最初发布在https://blog.daml.com/
本文来自投稿，不代表本人立场，如若转载，请注明出处：http://www.souzhinan.com/kj/291532.html