云架构
OCI区块链平台最新更新实现了区块链互操作性，并为OCI带来Web3功能
新版本概述
企业区块链用例的增长势头推动了区块链平台与其他系统（包括其他区块链分类账）之间的互操作性需求。为了更好地支持我们的客户和合作伙伴的需求， Oracle 区块链平台22.4.2版及其低代码区块链 App Builder 提供了许多新功能来帮助开发人员构建复杂的区块链解决方案。此版本的主要功能包括：
§ OAuth 2.0 支持 REST 代理事件回调，以启用由订阅组织的身份提供商验证的回调传递。这扩展了基于相互 TLS（证书交换）的当前安全模型，带有 OAuth 2.0 安全令牌选项，用于将需要将事件回调传递到其 OAuth 令牌安全企业系统的联盟网络中的成员集成。
§ 更流行的 web3 API 支持 OBP 用户在 OBP 节点上使用以太坊虚拟机 (EVM) 运行 Solidity 智能合约。随着越来越多的用户开始利用这些功能，这个版本已经认证了 web3 JSON RPC API 的 Fab3 提供者，使得使用标准 web3 接口使用 Solidity 智能合约变得更加容易。
§ 以太坊互操作性使开发人员能够在单个原子操作中将 OBP 原生智能合约交易与以太坊/EVM 智能合约交易相结合。此功能通过以太坊客户端扩展 REST 代理编排，以支持调用基于以太坊/EVM 的智能合约，作为先前发布的基于 2PC 的原子事务支持的一部分。原子提交确保双方都在 leger 上提交，或者，如果任何一方失败，则都不提交。
§ Blockchain App Builder 中扩展令牌化 SDK 和生成的链代码以支持新的 ERC-1155 规范，该规范允许在单个模板中定义可替代和不可替代的令牌并在单个链代码中运行。这种多令牌功能（包括批量传输）简化了更高级的令牌化解决方案。
§ 扩展基于 TTF 的令牌化 SDK 以支持 OBP 上不同可替代令牌之间的交换，这使得处理多种货币或具有可交换的不同品牌忠诚度积分的奖励系统的银行能够实现更复杂的金融用例。
此版本目前在所有受支持的 OCI 区域进行生产部署，可以通过配置新的 OBP 实例或将现有实例升级到最新版本来使用。有关这些特性的详细文档，请参阅最新的 Oracle 区块链平台新增功能。
OAuth2 安全令牌支持
OBP 一直支持入站 REST API 请求的 OAuth2，但事件订阅触发的回调由双向 TLS 保护，这取决于订阅系统必须向 OBP 颁发的 X.509 证书，并且 OBP 必须包含在回调过程中.虽然这是一种非常安全的方法，但颁发和更新 X.509 证书需要一些努力，而且并非所有参与方都能够运行为此目的所需的 PKI 系统。为了让不同的参与者更容易加入区块链联盟并使用事件通知/回调与他们的后台系统集成，我们着眼于提供更简单和更广泛访问的额外安全选项。 OAuth2 令牌在跨公司边界连接系统时被广泛使用，它们的令牌可以通过许多身份管理 ( IdM ) 解决方案自动发布或刷新。
使用 OBP REST 代理 OAuth 2.0 令牌支持的事件回调的请求/响应流
要将 OAuth2 令牌用于事件订阅回调，您必须在使用“ oauth ”参数结构注册事件订阅时为目标系统的 OAuth 服务器指定相关的客户端 ID、客户端密码和范围参数：
"oauth": {
"clientID": "my-client-id",
"clientSecret": "my-client-secret",
"tokenUrl": "https://identity.example.com/oauth2/v1/token",
"authInHeader": true,
"scopes": ["urn:opc:idm:__myscopes__"]
}
Web3 API 支持
Web3 API 是指开源web3.js 库使用的 API ，它是一组模块，允许您与本地或远程以太坊节点或以太坊虚拟机 (EVM) 模拟的节点进行交互。 OBP 长期以来一直支持EVM 选项，使 Solidity 开发人员能够在私有以太坊模型中轻松地在 OBP 上部署和运行他们的智能合约。过去，客户端dApp和 Solidity 智能合约之间的这些交互是通过 Remix Ethereum IDE 或 OBP REST 代理 API 实现的。然而，随着 web3 的日益普及，更多的开发者希望能够利用这一事实标准与包括 OBP 在内的多个网络上的智能合约进行交互。
为了支持这一点，此版本支持构建为 web3.js 库和 Hyperledger Fabric 之间网关的Fab3 模块。它向外部客户端公开 web3 JSON-RPC API，并通过 Hyperledger Fabric 客户端 SDK 在内部将这些请求映射到对 OBP 节点上的EVMCC 链代码的gRPC调用，从而实现与部署在 EVMCC 运行时中的 Solidity 智能合约的交互。这使得标准的基于 web3 的客户端（例如加密钱包和其他dApp ）能够在 OBP 上使用 Solidity/EVM 合约。
支持的 Fab3 提供程序启用 Web3 JSON-RPC API
以太坊与原子交易的互操作性
公共和许可区块链的世界越来越紧密。更多的客户和合作伙伴解决方案包含两种类型的分布式账本以满足复杂的要求，其中许可区块链的性能和机密性与公共区块链的更广泛的范围和流动性同样重要。 Oracle 区块链愿景完全包含这种互操作性，此版本通过 OBP REST 代理的编排功能实现了这一点。
在上一个版本中，我们提供了一个atomicTransaction功能，使应用程序能够在同一通道上或跨不同通道调用多个 OBP 智能合约，作为基于 2-Phase Commit (2PC) 协议的单个原子操作。它确保所有事务都将一起提交，或者，如果有任何事务失败，则所有事务都将回滚。虽然这是 Hyperledger Fabric 世界中的一项重大创新，但我们并没有就此止步。在此版本中，开发人员可以使用单个以太坊（或基于 EVM 的）智能合约扩展atomicTransaction API 中的智能合约列表，并仍然获得相同的原子结果——全部成功或全部回滚。
您可能会问这怎么可能，因为与 OBP 不同，以太坊不支持用于编排原子事务的 2PC 协议。答案在于2PC的LRC（Last Resource Commit）优化。它本质上使一个非 2PC 资源能够包含在基于 2PC 的全局事务中。在 OBP 交易的“准备”阶段之后，REST 代理使用内置的 Geth 客户端执行以太坊智能合约交易并等待其提交（基于 API 中提供的最终规则参数）。如果提交，则相关的 OBP 交易将进入自己的“提交”阶段。如果失败，则回滚“准备好的”OBP 事务。因此，我们用一个“ lrc ”段来扩展atomicTransaction API ，该段指定要调用的以太坊合约和一组与以太坊调用相关的参数，包括关于多少块或等待以太坊端提交多长时间的最终性参数。
以太坊与 OBP REST 代理协调的 OBP 互操作性
以下示例显示了 API 详细信息，其中包含用于 OBP 链代码调用的事务数组和用于以太坊合约调用的lrc部分。 lrc部分包括一个用于签名或未签名交易请求的 ethReq 部分，以及一个finalityParams部分，它确定等待交易最终确定的时间。
{
"transactions": [
{"chaincode":"bt1","args":["invoke", "a", "b", "7"],"timeout":0, "channel":"ch1"},
{"chaincode":"bt2","args":["invoke", "a", "b", "5"],"timeout":0, "channel":"ch2"}
],
"lrc": {
"ethReq": {
"url": "http://<IP address of Ethereum server>:<port>",
"chainId": 1337,
"unSignedReq": {
"privateKey": "de1fab4e05b476f81d11901a69e58a3000859395eb6bdb222fcb583b8d599b00",
"ethValue": "1000000000000000000",
"gasLimit": 21000,
"toAddress": "0x7336d04f97fdccd0a93462947474c8879a5c6597"
},
"finalityParams": {
"checkFinality": true,
"blocksToWait": 2,
"secondsToWait": 30
}
}
},
"isolationLevel": "serializable",
"prepareTimeout": 10000,
"sync": true
}
的unSignedReq部分也可以替换为signedReq ：
"ethReq": {
"url": "<a href="https://goerli.infura.io/v3/d0263407d1bc4fff9658f420b9e6b5bc">https://goerli.infura.io/v3/d0263407d1bc4fff9658f420b9e6b5bc</a>",
"chainId": 5,
"signedReq": {
"signedTxHex" : "02f8950506841ad2748084476807808401406f409442efb56de8e6a516fff899c9263ef3d21ffd9c298502540be400a4e3456fa90000000000000000000000000000000000000000000000000000000000000001c080a074c985cce323b924e5503592a1301e301c4a3fa4c55234cf60b2782dce81e825a0605b9f61113057e02f614b4d2a52fc5953719aec30743ff4d8b7e2bbf3a206b5"
},
"pendingTimeout": 420,
"finalityParams": {
"checkFinality": true,
"blocksToWait": 10,
"secondsToWait": 20
}
}
以太坊交易的结果可以在 Goerli 的Etherscan视图中看到 测试网。
Etherscan将 OBP 发起的以太坊测试网交易视为全局原子交易的一部分。
支持原子事务的以太坊互操作性使许多场景能够支持大量互操作性用例：
· 原子资产交易所
o 使用 ETH 或 ERC-20代币预先资助 OBP可替代代币
o 使用 ETH 或 ERC-20 代币支付在 Oracle 区块链上铸造和交易的 NFT
o 在 Oracle 区块链上准备和铸造 NFT，允许 NFT 买家转移到以太坊或另一个基于 Solidity/EVM 的网络以获得二级市场流动性
· 使用 OBP 代币跟踪跨多个分类账或市场的公共链代币余额
· 使用机密业务数据的 OBP 交易处理会生成触发以太坊智能合约的事件，例如，处理支付或其他复杂的业务流程
· 基于机密账本数据的 OBP 交易将其哈希作为公开证明发布在以太坊上，但不披露任何机密交易细节
ERC-1155支持
除了 NFT 的初始 ERC-721 规范之外，还提出了许多新规范，以各种方式扩展 NFT 以处理更复杂的用例、更大的可监管性等。ERC-1155 中更流行的扩展之一，它在单个合约中结合可替代和不可替代的代币，支持跨多个代币的批量交易，并提供更多动态的 NFT 属性。作为领先的低代码区块链开发工具，我们的 Blockchain App Builder 现在允许您通过在代币模板中使用“标准：erc1155+”并定义多种资产来指定 ERC-1155 代币，这些资产可以包括可替代和不可替代的代币以及非代币资产。最新版本的 Blockchain App Builder 中包含一个使用“erc1155+”标准的示例模板。
作为一种多代币数字资产规范，ERC-1155 在单一合约中结合了 ERC-20（可替代）和 ERC-721（不可替代）资产的优点，并允许您将可替代代币转换为 NFT（例如，支付对于具有一定数量的忠诚度积分或硬币的 NFT）。使用单个 ERC-1155链代码，一个用户帐户可以创建和持有多个可替代和 NFT 代币资产，这与 ERC-721 不同，ERC-721 将单个 NFT 链接到一个帐户。 ERC-1155 还通过单一智能合约方法提供批量转账，并通过允许安全转账功能验证交易有效性并在交易无效时撤销交易来提供更高的安全性。批量转账不仅使转移多个资产变得更容易和更快，而且为更复杂的 NFT 工具打开了大门。在单个操作中在 NFT 和可替代代币之间转换的能力将优化许多与NFT 相关的交易，并启用新的代币化用例。
不断发展的标记化规范
“erc1155+”标准中的那个“+”呢？就像 ERC-721 一样，我们扩展了 ERC-1155 以包括销毁方法、账户管理功能（创建、关联、暂停和恢复链上托管账户），以及基于角色的安全性来控制谁可以铸造和销毁这些代币.很快就会找到关于 ERC-1155 功能的更详细的帖子。
代币的代币交换
可替代代币的一些更流行的用例是在金融领域，其中代币代表数字货币，或者在奖励计划中，它们代表不同品牌的忠诚度积分。在这两个领域中，货币之间的兑换或品牌之间忠诚度积分的兑换都是重要的要求。有几种交换代币的方法，我们选择了一种发展最快的机制，称为交换池（又名流动性池）。交换池的模型类似于金融系统或加密货币中的流动性池概念——这些只是由受信任方维护的包含多种货币的账户。它们可以由称为流动性提供者的任何其他方提供资金，流动性提供者将资金转移到交换池，通常以换取从交换池用户收取的费用。然而，我们不必依赖外部流动性池，我们允许用户直接在 OBP 分类账上创建和资助它们作为我们标记化引擎的一部分，并使流动性提供者能够作为成员加入 OBP 以将资金转移到 OBP 交换池中。
要使用令牌交换方法，您需要首先调用方法来设置交换池设施并设置转换率。然后来自多个代币系统的流动性提供者可以将代币转移到其中，为交易所池账户提供资金。准备就绪后，交换本身通过单个方法调用完成：
TokenConversion(from_token_id string, to_token_id string, to_org_id string, to_user_id string, token_quantity float64)
例如： TokenConversion ( “ TokX ”, “ TokY ”, “Account2”, “Account2_user”, 10)
当通过此 API 调用时，标记化 SDK 然后从账户 1（调用者）启动交换交易，将 10 个单位的TokX作为TokY交付给账户 2 。在幕后，这涉及将 10 TokX转移到交易池账户，在该账户中记入并从交易池中扣除相应数量的TokY （基于通过池 API 设置的汇率）并转移到目标账户。
Oracle 区块链令牌化引擎中的交换池机制
例如，假设我们有一个名为 USD 的代币和另一个名为 EUR 的代币，以及一个为 USD 和 EUR 定义的兑换池，资金为 100 单位美元和 70 单位欧元，兑换率设置为 0.95 欧元兑 1 美元。我们可以从账户 1 调用转账方法，将 10 美元以欧元交付到账户 2。这将借记账户 1 的 10 美元代币，将这些记入交易池美元账户，借记交易池欧元账户 10.52 欧元代币 (10/0.95)，并将此金额记入账户 2 的欧元。结果，系统中的美元和欧元总额保持在交易前的水平，我们通过在兑换池账户中贷记和借记所需金额实现了兑换。这种机制类似于外汇交易中使用的做市商，系统性银行通常提供流动性池服务。通过我们的代币交易所，您可以实施多币种 CBDC 系统或任何需要在多币种世界中运作的金融工具。
概括
区块链用例的复杂性正在上升，随之而来的是对互操作性的强烈需求——与其他企业系统和跨多种区块链技术。使其不仅具有功能性，而且易于使用和易于保护是许多区块链平台面临的挑战。最新的 Oracle 区块链平台版本通过以下方式解决了这些挑战：
· OAuth2 令牌支持使事件回调的企业集成更容易在成员的企业IdM生态系统中得到保护，并且具有更广泛的吸引力。
· 能够以原子方式跨不同的区块链通道执行多个事务对于许多用例来说至关重要。除了 Oracle 区块链平台之外，没有其他区块链实现支持此类用例，而无需更改现有链代码和/或引入复杂且易受攻击的桥接解决方案。
· 借助用于 web3 JSON-RPC API 的 Fab3 提供商，我们可以更轻松地将常见的加密钱包和dApp与 OBP 上的 Solidity/EVM 合约集成。您可以使用它在 OCI 中的托管 OBP 服务上运行私有 Solidity/Ethereum 解决方案，并与标准钱包和其他dApp 集成。
· 随着 NFT 超越数字艺术和收藏品，需要更高级的功能来模拟不同形式的资产，结合可替代和不可替代的功能。借助 ERC-1155，我们使开发人员能够充分利用最新方法，使 NFT 更有用，更容易适应现实世界的用例。
· 通过可替代的代币交换，我们使数字货币或奖励计划能够利用 OBP 支持的交换池机制在多货币或多品牌的世界中轻松运作。
所有这些以及许多其他创新功能都展示了 Oracle 区块链支持您今天的明天的强大功能。