文昌链最佳实践建议

简介

感谢技术社区对于文昌链的信任，随着文昌链支持的应用越来越多，我们关注到技术社区中许多开发同学遇到的共性问题。为此我们决定写一篇最佳实践来指导解决大家的问题

概念介绍

节点分类：

共识节点：区块链网络中负责出块的网络

全节点：区块链网络中负责接收查询交易的节点（不参与共识）

实施建议

建议1: 加入文昌链技术社区，关注社区讨论及技术团队的咨询回复

文昌链现在的业务发展非常快，技术服务团队会第一时间更新链的服务发展，例如：

链升级内容及对用户的影响

产品升级内容及对用户的影响

升级时间对用户造成的影响

SDK & AVATA 的更新内容及对产品的影响

同时社区中还有其他热心社区成员提供帮助，有机器人帮助你找到不同资源的入口

建议2: 使用 Sync 模式而不是 Commit 模式或 Async 模式提交交易

不同交易模式的解释：

Commit 模式：用户提交交易后会建立一个结果接收线程等待链通知交易执行的结果；

Sync 模式：用户提交交易后会链经过验证后会返回给用户一个交易 hash

Async 模式：用户提交交易后，立刻返回一个交易 hash

为什么要使用 Sync 模式？

Commit 模式 不推荐使用：在链的并发较大时，可能会导致等待线程超时，无法把当前交易的执行结果返回给用户。如果链的压力比较大的时候，交易可能无法发送。（未来的计划是会删除此种交易模式）

Sync 模式 推荐使用：对于用户提交的交易，Sync 模式发送的交易，只需要经过了合法性验证就可以进入 mempool(交易池) 等待被广播到共识节点，用户如果想要拿到结果，仅需要查询一次提交交易返回的 hash 即可，读写分离，性能高

Async 模式 不推荐使用： Async 模式不做任何的交易校验执行，仅会根据当前的交易内容返回一个 hash，用户无法感知交易是否被发送到链上。

示例

OPB-SDK-Go

对于使用 opb-sdk-go 的用户在配置的时候请做如下配置：

OPB-SDK-JAVA

对于使用 opb-sdk-java 的用户在配置的时候请做如下配置：

建议3: 离线维护 Sequence/Nonce 并配合 Sync 模式

推荐架构如下：

示例

对于 OPB-SDK-Go

opb-sdk-go 默认做了维护 sequence （注意：不要完全信任，这个值是存在于内存中的，如果网络抖动，可能会导致 sequence 不对）可以用如下方式自己本地静态维护：

签名和广播分开（推荐做法，和架构图一致）

签名和广播不分开

注意： opb-go-sdk v0.2 会自动在内存中维护账户的 sequence ，但不要过度信任，在大多数情况下是可用的，但在网络特别差的时候可能会出现意外。

对于 OPB-SDK-JAVA

建议4：对于 EVM 交易和 DDC 的并发交易必须离线维护 Nonce

所有的交易是由全节点接收的。
当区块链网络的压力比较大时，全节点的交易可能无法被及时的广播到共识节点，如果不离线维护 Nonce 值，可能会导致出现一些关于 Nonce 值的错误；

使用建议

如果你是使用 DDC-SDK-Java 的用户请使用 SDK 中 setNonce 的操作

如果你是使用其他 web3 SDK 请根据他们文档中提供的方式设置 Nonce

最佳实践架构和建议3 类似

注意： 对于 EVM 交易，正确的做法是：发送完一笔交易后查询一下交易的执行结果。 EVM 的目前的机制是调用失败 Nonce 值不会增加

简介#

概念介绍#

实施建议#

建议1: 加入文昌链技术社区，关注社区讨论及技术团队的咨询回复#

建议2: 使用 Sync 模式而不是 Commit 模式或 Async 模式提交交易#

不同交易模式的解释：#

为什么要使用 Sync 模式？#

示例#

OPB-SDK-Go#

OPB-SDK-JAVA#

建议3: 离线维护 Sequence/Nonce 并配合 Sync 模式#

示例#

对于 OPB-SDK-Go#

签名和广播分开（推荐做法，和架构图一致）#

签名和广播不分开#

对于 OPB-SDK-JAVA#

建议4：对于 EVM 交易和 DDC 的并发交易必须离线维护 Nonce#

使用建议#

简介