欢迎来到 STACS-Native

前言

区块链是一个分布式的公共账本，这个账本由各个区块连成一个链条。在区块链这个“账本”上，链条上的每一个点都能在上面记录信息，构成点对点的记账系统。去中心化 / 多中心化的由多个业务参与方共同维护同一个账本，是区块链技术的主要特征。

这一去中心化 / 多中心化技术，使得相互不完全信任彼此的组织可以通过使用协议，能对提交给共享账簿的更新达成一致。在同一区块链网络上，参与者查询到的数据一致，并且数据能在被信任的业务网络上安全地共享，同时实现数据防篡改、可溯源。

区块链最早的诞生和应用场景是以比特币为代表的加密数字货币，这也是目前区块链应用最为成功的场景。在加密货币的场景下，区块链本身只需要实现一个分布式的、去中心化的账本，准确的记录每个参与者的数字资产，并不会参与到现实世界的业务场景中，因此只要在密码学和分布式技术上的实现，就足够支持加密货币的商业场景。

随着区块链产业的不断发展，当我们开始考虑将区块链技术应用于更多的商业场景时，我们发现大部分业务场景要远远比“记录数字资产和转账”更加复杂，这些复杂性体现在以下几个方面：

  • 商业逻辑本身并不是完全去中心化的，不能简单的使用去中心化的共识来实现，也就是说，PoW（算力最大者决定记账结果）PoS（ 资产最多者决定记账结果）PBFT（节点数量决定记账结果）等经典意义上的区块链共识算法并不符合现实世界的商业逻辑；
  • 对于大部分交易场景来讲，尤其是金融交易场景，匿名交易是不可接受的，区块链应当有某种办法去记录交易双方的身份并由此判断交易是否可以进行；
  • 现实世界的交易是具有私密性的，尤其在非匿名的交易场景下。区块链的全网共享账本需要有技术可以满足业务的灵活性和交易的可私密性，同时可以满足监管的要求 ，即不能存在监管之外的私密性；
  • 商业机构的业务实现需要按照现实世界的法律规则和商业规范来决定业务是否可以被执行，区块链共识+智能合约很有用，但缺乏和现实世界交互的能力，“代码即法律”和现实世界有不兼容性；
  • 基于以上的现实业务需求，我们设计了专门为金融市场量身定做的STACS-Native区块链。

在以下章节中，介绍了区别于其它区块链技术，STACS-Native是如何为金融市场实际业务设计，并满足金融市场需求。

什么是STACS-Native？

STACS-Native是一个为专为金融和交易业务而优化设计的区块链系统，STACS-Native被设计为支持金融机构间进行交易清算的可信区块链（也称为联盟链），其设计目标是为用户提供更可靠、稳定、灵活易用的可支撑复杂业务的区块链系统。

多个不同的STACS-Native区块链可以通过STACS-Global区块链连接在一起，实现互相之间的数据跨链交换和交易跨链执行，即使这些STACS-Native本身是经过定制化的，或者是由不同的机构和社群进行维护。并且这种可连接性是由STACS-Native自行决定的 - 也就是说，STACS-Native网络可以自己决定是否要通过STACS-Global和其他STACS-Native网络交换数据，以及何时进行交换。

STACS-Native同时提供了良好设计的去中心化应用程序沙盒（DApp Runtime Sandbox），帮助机构客户和第三方开发者社区无需理解区块链技术的复杂概念，通过便捷的开发环境，编写去中心化应用程序（DApp），同时还将很快上线DApp的AppStore，方便第三方开发者发布和部署STACSDApp，我们希望STACSDApp能够像苹果的AppStore一样易于使用，如果说苹果通过AppStore使得开发者在完成一个iOS应用程序开发之后，可以容易的运行在全世界所有运行iOS系统的苹果的设备上，那么我们的目标就是让第三方开发者开发的STACSDApp可以运行在全球数千个STACS-Native的区块链节点上。

以下我们将简要介绍STACS-Native的一些重要特性：

Policy（业务投票规则）

STACS区块链创造性的设计了双层区块链共识机制 - 业务共识和数据共识。

当我们将STACS区块链和现实世界的金融业务进行集成时，我们意识到区块链的数据共识并不能很好满足客户的商业需求。以BTC为代表的区块链系统，只需要保证私钥的正确性（证明数字资产的所有权）和数据正确性（保证数字资产的数量正确）即可完成交易，但现实世界的商业逻辑要求更多的确认：这笔交易是否满足交易多方的商业逻辑？是否符合法律和金融监管的要求？是否满足客户认证/反洗钱的要求？这些来自现实世界的需求都将通过Policy（业务策略）得到满足。业务共识是STACS区块链和现实世界的金融和商业逻辑进行结合落地的重要设计。

数据共识：区块链可以使用PoW / PoS（它们常用于公链）和PBFT/RAFT（常用于联盟链）的共识算法来保证区块链全网数据的一致性。对于STACS来说，我们选择了和主流的区块链选择了同样的技术方案，在数据层面的共识算法上，我们使用PoS（应用于STACS-Global公链）和RAFT（应用于STACS-Native联盟链）进行数据的一致性共识。

业务共识：业务共识是STACS区块链独有的共识机制。业务共识主要解决参与交易的多个业务方之间是否能够就交易执行的商业逻辑、合同和法律达成共识。STACS区块链使用Policy完成业务共识。

详细信息， 可以参考Policy。

Domain（链上机构）

当我们运行业务共识（Policy）策略时，我们需要一个或多个业务参与方，对交易的业务正确性进行投票。一个很基础的问题是：我们如何在区块链上确认业务参与方的投票权呢？

其他区块链技术给予我们如下选择，但都不能够满足业务需求：

通过PoW的方式进行算力投票：很明显，在现实世界中，我们不能以算力强弱作为业务投票权的选择。想象一下Domain在STACS-Native中多个机构之间，一个Domain可以拥有一个或多个节点。STACS-Native中大多数的投票都是Domain为单位，采用一票通过的设计原则，即在Domain中，只要有一个节点背书投票，则认为Domain背书投票。可以在一个金融机构拥有节点投票比重较大时，保护机构间的公正性，避免节点竞争，从而保证去中心化的信任基础；同时可以解决外部请求的单节点故障问题。

详细信息， 可以参考Domain。

DRS平台(通用运行环境)

STACS-Native独有的DRS平台，方便开发者开发、上传DApp应用。同时，用户可通过DRS对DApp进行下载、安装、卸载、管理等操作。DRS的主要特性如下：

  • 标准设计规范和API接口：标准的设计规范允许开发者在DRS平台上进行无缝应用开发。
  • 完整生命周期管理：为金融DApp应用提供标准运行环境以及DApp完整生命周期的管理。用户可在DRS上的一键完成DApp安装，部署变得容易。
  • 稳定的操作环境：DRS集成了运行DApp匹配的插件和文件，DRS内可以运行一个或是多个DApp，DRS中运行的每个DApp都相互隔离。同时DRS还封装了与CRS（Common runtime sandbox）的通信过程，简化DApp的接入流程。DRS通过某一Domain的Load-balance(LB)连接到Domain所属的任一节点。通过这种方式实现了DRS与Domain通信的高可用与稳定性。

STACSDApp(去中心化应用程序)

STACSDApp（STACS分布式应用程序）是运行在STACS DRS平台上的分布式应用程序。STACSDApp主要特性如下：

  • DApp是具有一定打包规范的Java工程，采用Maven管理相关依赖，支持任意Java项目，包括Web项目。
  • 可以安装并运行在DRS平台上，由DRS管理其整个生命周期：下载、配置、安装、卸载、更新等。
  • DApp可以通过调用DRS提供的API快速接入底层区块链平台，无需复杂配置。
  • 支持基于BD业务规则的相关API：Policy、Identity、Contract等。
  • DRS封装了面向区块链平台的交易处理及回调接口，实现对DApp复杂业务的封装。

详细信息， 可以参考STACSDApp。

私有数据

STACS-Native特别为金融业务提供了私有数据交易，用于不同机构间进行私密交易。在进行私密交易前会先约定交易方，并通过密钥交换技术生成密钥，交易发起方发给交易密文给确认方，确认方解密并验证，同时附上验证结果；发起方在确认方确认无误后发起交易，该交易为私密交易，交易内容为密文同时会上链，以便后续审计与追溯。

详细信息， 可以参考私有数据。

智能合约

STACS-Native采用Solidity语言作为智能合约的程序代码，在Solidity的基础上增强预编译合约，提高了系统的可靠性。

详细信息， 可以参考智能合约。

共识协议

插拔式共识协议

STACS-Native为金融业务场景设计，支持插拔式共识协议。同时支持BFT（Byzantine Fault Tolerance）拜占庭容错协议和CFT（Crash Fault Tolerance）故障容错协议是STACS-Native的特点之一。该协议使平台能够更有效地自定义，能够更为有效的适应特定的用例和信任模型：

  • BFT拜占庭容错协议适用于多企业构建的区块链网络。
  • CFT故障容错协商一致协议适用于单一企业或受信企业网络中，可有效提高网络处理性能。

详细信息， 可以参考共识协议。

P2P结果确认(点对点共识)

P2P结果确认是STACS-Native共识协议中的另一个特点。在交易执行完成后，通过P2P确认，2f+1个节点的执行结果一致时，才会回调上层业务。

财务模型

STACS-Native支持UTXO和余额模型两种账务模型：

  • UTXO（Unspent Transaction Output）：UTXO交易是由一笔或多笔“交易输入”，产生一笔或多笔“交易输出”，所产生的“交易输出”又称“未花费的交易输出”。任何一笔“交易输入”都是前序某个交易当中产生的“未花费交易输出”，就像接链条一样，前后互相链接，前一个链条块的输出就是后一个链条块的输入。
  • 余额模型：余额模型采用复式记账法中的借贷记账法，即以“借”、“贷”为记账符号的一种复式记账法。

BD（业务规范）

BD（Business definition，业务定义）是指定义一整套完整的包含所有业务相关功能的业务规范，可以有一个或多个DApp协作执行整套业务。BD定义了初始化所需Permission和Policy，并指定每个功能的类型、方法签名、执行Permission以及执行所需的Policy策略。

详细信息， 可以参考业务定义。

业务Master(区块构造节点)

业务Master主要负责交易的排序打包，保证各个节点交易线性一致执行。采用从1递增的任期序号，标识当前唯一Master，用于选举及保证各节点收到交易的一致性。在初始启动或是一段时间内没有收到Master心跳时，任一节点都会向其他节点发起Master选举，当获得2f+1个节点一致认可后，节点将成为下一任业务Master。

如果你想更加详细的了解系统的设计？ 可以参考架构设计。