Type Members

1.  case class AlreadyDeployed(address: String, blockToReadFrom: BigInt) extends SequencerContractConfig with Product with Serializable
   address

   Address to which the Sequencer contract was deployed.

   blockToReadFrom

   Should usually be the block number (decimal, not hexadecimal number) to which the sequencer contract was deployed. When first starting and initializing a Canton sequencer, we start to read and to look for Sequencer-contract emitted events starting from this block (inclusive). The sequencer persists the last block height it processed, so this value does not need to be updated when simply restarting a sequencer.

2.  case class AutomaticDeployment() extends SequencerContractConfig with Product with Serializable
3.  case class Besu() extends EthereumClient with Product with Serializable
4.  case class Bip39Wallet(password: Password, phrase: Password) extends WalletConfig with Product with Serializable
5.  case class ClientConfig(clientHost: String, clientPort: Port) extends Product with Serializable
6.  sealed trait EthereumClient extends Product with Serializable
7.  case class GasConfig(price: BigInt = 0, limit: BigInt = 0x1fffffffffffffL / 1000) extends Product with Serializable

   Static gas configuration for all sequencer transactions (including the transaction deploying the sequencer contract) Defaults were picked as suitable for a besu free gas network with up to 1000 transaction per block

   Static gas configuration for all sequencer transactions (including the transaction deploying the sequencer contract) Defaults were picked as suitable for a besu free gas network with up to 1000 transaction per block

   price

   How much GWei are we willing to pay in gas per transaction

   limit

   The gas limit for a single transaction (in gas so the limit of computation cost not ether cost)

8.  case class RandomWallet() extends WalletConfig with Product with Serializable
9.  sealed trait SequencerContractConfig extends AnyRef

   An Ethereum sequencer can be configured to either interact with a predeployed Sequencer contract or automatically deploy a new contract that it will interact with when it's initialized.

   An Ethereum sequencer can be configured to either interact with a predeployed Sequencer contract or automatically deploy a new contract that it will interact with when it's initialized.

   Note that when initializing multiple sequencers at the same time (e.g. via bootstrap_domain) and setting the sequencers to automatic deployment, each sequencer will deploy its own contract at a different address. For the multi-sequencer setup, we thus recommended to first deploy a sequencer contract (see console command deploy_sequencer_contract) and then configure the sequencers to interact with the already deployed contract.

10.  case class TlsConfig(cantonKeyStore: KeyStoreConfig, ethereumCertificatePath: String) extends Product with Serializable

    TLS configuration between Canton and Ethereum client.

    TLS configuration between Canton and Ethereum client. Only supports using mutual authentication

    cantonKeyStore

    The certificate used by Canton when communicating with the Ethereum client

    ethereumCertificatePath

    The certificate Canton will expect the Ethereum client to use. Should be a path to the public key in X509 format (".pem")

11.  case class UTCJsonWallet(password: Password, walletPath: String) extends WalletConfig with Product with Serializable
12.  case class ValidationConfig(checkIfFreeGasNetwork: Boolean = true, blocksBehindBlockchainHead: Long = 500) extends Product with Serializable

    Configuration for when Canton should log warnings that the configuration of Canton or the Ethereum network may be faulty.

    Configuration for when Canton should log warnings that the configuration of Canton or the Ethereum network may be faulty. This configuration has no functional impact on the Canton sequencer or the Ethereum network.

    checkIfFreeGasNetwork

    should the Canton sequencer log a warning if it isn't connected to a free-gas network

    blocksBehindBlockchainHead

    when should Canton warn that it is currently processing blocks that are behind the latest block in the blockchain

13.  sealed trait WalletConfig extends Product with Serializable

    Wallet configuration for the account that will be used for submitting transactions to the deployed Canton sequencer smart contract.

    Wallet configuration for the account that will be used for submitting transactions to the deployed Canton sequencer smart contract. Accounts are configurable via a standard web3 wallet (type="file-based-wallet") as well as via a Bip39-based wallet (type="bip-39-based-wallet"). If no wallet is specified, a random account is generated and used (only recommended for zero-gas networks).

    Note that by default the Canton integration assumes that it's the only application submitting transaction for a given account and thus assumes the transaction nonce for that account doesn't change except due to Canton-submitted transactions. If you have configured a custom wallet and will submit transactions to the blockchain for the same account from another application, then you need to set checkNonceBeforeEverySubmission to true. In this case, Canton will query the current account nonce before every transaction submission. Note that transactions may still fail with, e.g., "Nonce too low" and will need to be retried if submitting concurrent transactions for the same Ethereum account.

14.  case class Web3jConfig(pollingInterval: PositiveFiniteDuration = PositiveFiniteDuration.ofMillis(350), transactionReceiptPollingInterval: PositiveFiniteDuration = PositiveFiniteDuration.ofSeconds(10), transactionReceiptPollingAttempts: PositiveInt = PositiveInt.tryCreate(6)) extends Product with Serializable

    Advanced Web3j configuration options.

    Advanced Web3j configuration options. You will likely not need to adapt these.

    pollingInterval

    How frequently should web3j check whether a new block in the blockchain has been mined?

    transactionReceiptPollingInterval

    How often should web3j check that a submitted transaction has been accepted? This is mostly informational so can do at a much lower frequency.

    transactionReceiptPollingAttempts

    How many polling attempts should be made to see if a transaction has been accepted? With the default transaction receipt polling interval this will allow a window of 60s which should be greatly more than needed.