Optimize the configuration switch used for zkSNARK and shielded transaction

[Federico2014]

A switch option exists in the configuration used to determine whether to allow shielded transactions API.

node.fullNodeAllowShieldedTransaction

Here are two related optimizations.

zkSnark parameters initialization

The default value of fullNodeAllowShieldedTransaction is true. However, if we set fullNodeAllowShieldedTransaction = false, the FullNode will skip the zkSnark parameters initialization process, as follows:

public static void librustzcashInitZksnarkParams() {
  logger.info("init zk param begin");
  if (!JLibrustzcash.isOpenZen()) {
    logger.info("zen switch is off, zen will not start.");
    return;
  }
  String spendPath = getParamsFile("sapling-spend.params");
  String spendHash = "25fd9a0d1c1be0526c14662947ae95b758fe9f3d7fb7f55e9b4437830dcc6215a7ce3ea465"
      + "914b157715b7a4d681389ea4aa84438190e185d5e4c93574d3a19a";
  String outputPath = getParamsFile("sapling-output.params");
  String outputHash = "a1cb23b93256adce5bce2cb09cefbc96a1d16572675ceb691e9a3626ec15b5b546926ff1c"
      + "536cfe3a9df07d796b32fdfc3e5d99d65567257bf286cd2858d71a6";
  try {
    JLibrustzcash.librustzcashInitZksnarkParams(
        new LibrustzcashParam.InitZksnarkParams(spendPath, spendHash, outputPath, outputHash));
  } catch (ZksnarkException e) {
    logger.error("librustzcashInitZksnarkParams fail!", e);
  }
  logger.info("init zk param done");
}

In this case, the FullNode cannot process shielded transactions. An error will occur if it attempts to synchronize blocks that contain shielded transactions. Therefore, the zkSnark parameters must be initialized regardless of whether fullNodeAllowShieldedTransaction is set to true or false.

fullNodeAllowShieldedTransaction should be kept to control the shielded transaction API. So it is necessary to remove the following code snippet from the zkSnark parameters initialization function:

if (!JLibrustzcash.isOpenZen()) {
  logger.info("zen switch is off, zen will not start.");
  return;
}

pushTransaction

Furthermore, fullNodeAllowShieldedTransaction also affects the behavior of pushTransaction. However, relying on it is not recommended, as the execution of shielded transactions is ultimately governed by the ALLOW_SHIELDED_TRANSACTION proposal.

if (isShieldedTransaction(trx.getInstance()) && !Args.getInstance()
    .isFullNodeAllowShieldedTransactionArgs()) {
  return true;
}

So the above code snippet should be replaced by:

if (isShieldedTransaction(trx.getInstance()) && !chainBaseManager.getDynamicPropertiesStore()
    .supportShieldedTransaction()) {
  return true;
}

[troncommons]

Yes, parameter initialization should not be tied to the API configuration, as it could affect transaction processing.

[Sunny6889]

To be clear:

• chainBaseManager.getDynamicPropertiesStore().supportShieldedTransaction() is used to controll whether TRON support broadcast/process system shielded transactions on chain, currently it always return false, thus TRON not allow system shielded transactions. TRON only support shielded transactions in smart contract, it is controlled by Proposal No.39 .
• As shielded transactions in smart contract also need JLibrustzcash.isOpenZen(), which in existing logic is controlled by node.fullNodeAllowShieldedTransaction. (This part we need to remove)
• Thus, an error will occur if the FullNode turn node.fullNodeAllowShieldedTransaction=false, then it attempts to synchronize blocks that contain shielded transactions in smart contract.
• node.fullNodeAllowShieldedTransaction should be used to toggle whether the FullNode allow certain shielded related APIs, such as wallet/createshieldedtransaction to build the transaction. Notice it is different with wallet/broadcasttransaction to process and put shielded transactions on Chain.

[Federico2014]

There are some additional points to mention.

zkSNARK

Both JLibrustzcash and JLibsodium contain an isOpenZen flag, which is currently controlled by fullNodeAllowShieldedTransaction. As mentioned in the issue above, the loading of the zk-SNARK libraries should not depend on the fullNodeAllowShieldedTransaction configuration. Therefore, the isOpenZen flag should be removed from both libraries.

public static boolean isOpenZen() {
  boolean res = CommonParameter.getInstance().isFullNodeAllowShieldedTransactionArgs();
  if (res) {
    INSTANCE = LibrustzcashWrapper.getInstance();
  }
  return res;
}



private static boolean isOpenZen() {
  boolean res = CommonParameter.getInstance()
      .isFullNodeAllowShieldedTransactionArgs();
  if (res) {
    INSTANCE = LibsodiumWrapper.getInstance();
  }
  return res;
}

ShieldedTransferActuator

Whether ShieldedTransferActuator is allowed to execute transactions should be controlled by proposals. The current approach of using fullNodeAllowShieldedTransaction in the code is also inappropriate.

if (CommonParameter.getInstance().isFullNodeAllowShieldedTransactionArgs()
    && !merkleContainer.merkleRootExist(spendDescription.getAnchor().toByteArray())) {
  throw new ContractValidateException("Rt is invalid.");
}



if (CommonParameter.getInstance().isFullNodeAllowShieldedTransactionArgs()) {
  IncrementalMerkleTreeContainer currentMerkle = merkleContainer.getCurrentMerkle();
  try {
    currentMerkle.wfcheck();
  } catch (ZksnarkException e) {
    ret.setStatus(fee, code.FAILED);
    ret.setShieldedTransactionFee(fee);
    throw new ContractExeException(e.getMessage());
  }

RpcApi

Currently, the RPC API for shielded transactions is governed by proposals, which is not appropriate. It should be switched to be controlled via fullNodeAllowShieldedTransaction.

private void checkSupportShieldedTransaction() throws ZksnarkException {
  String msg = "Not support Shielded Transaction, need to be opened by the committee";
  if (!dbManager.getDynamicPropertiesStore().supportShieldedTransaction()) {
    throw new ZksnarkException(msg);
  }
}

private void checkSupportShieldedTRC20Transaction() throws ZksnarkException {
  String msg = "Not support Shielded TRC20 Transaction, need to be opened by the committee";
  if (!dbManager.getDynamicPropertiesStore().supportShieldedTRC20Transaction()) {
    throw new ZksnarkException(msg);
  }
}

It should be noted that fullNodeAllowShieldedTransaction currently controls both the HTTP and RPC API for system-level shielded transactions and shielded smart contract transactions. To ensure the availability of the shielded smart contract API, fullNodeAllowShieldedTransaction should be set to true. However, this also means that the system-level shielded transaction API becomes accessible, even though such transactions cannot be executed on-chain.

[3for]

Current Status:

• In the executeShielded function of ShieldedTransferActuator, the fullNodeAllowShieldedTransaction API switch is used, but the proposal switch is not checked. The API switch should be removed, and a check for the dynamicStore.supportShieldedTransaction() proposal switch should be added instead.
• In the validate function of ShieldedTransferActuator, the proposal switch is already being checked. The unnecessary check for the CommonParameter.getInstance().isFullNodeAllowShieldedTransactionArgs() API switch should be removed.
• The Wallet interface currently performs a fullNodeAllowShieldedTransaction API switch check. However, there are inconsistencies between the control mechanisms of the RPC API and HTTP API:
  • In the RPC API, some APIs perform a checkSupportShieldedTRC20Transaction() or checkSupportShieldedTransaction() proposal switch check, and also perform a fullNodeAllowShieldedTransaction API switch check in the corresponding Wallet interface. As a result:
    • If the proposal is disabled, the related APIs will not work, even if the API switch is enabled.
    • If the proposal is enabled, the API behavior is fully controlled by the API switch.
  • In the HTTP API, only the fullNodeAllowShieldedTransaction API switch check is performed via the Wallet interface, without any proposal switch check. This leads to the following behavior:
    • Regardless of whether the proposal is enabled, the API behavior is entirely controlled by the API switch.

There should be a clearer distinction between the purposes of the proposal switch and the API switch, and the behavior control of RPC and HTTP APIs should be made consistent.