Understanding Truffle's default configuration values (based on Ethereum), in particular surrounding polling intervals; and using 2 relatively new config options allows one to config Truffle to better connect to an RSK node. Public Nodes When connecting to , it is crucial to understand that you are interacting with the nodes . Each RPC request goes through a series of hops through other infrastructure, such as authentication gateways, load balancers, rate limiters, et cetera. Each of these other layers contains its own logic that may be more restrictive than the node itself. public nodes indirectly You may opt to work around this by running your own node on . localhost Ethereum Defaults Truffle's is optimised for the Ethereum network. However, some of these values are incompatible with the RSK network, and need to be accordingly. Remember that while RSK is compatible with Ethereum both at the RPC level and at the VM level; its internal implementation can be quite different. default configuration overridden The main difference lies in the relationship between and . block interval polling interval The is the duration of time between a block being added to the blockchain and the next one being added. Note that all transactions must be in a block in order to be added to the blockchain (AKA "has been mined"). block interval RSK's block interval is currently approximately 30 seconds, whereas Ethereum's block interval is currently approximately 15 seconds. Client applications, such as decentralised applications, or in this case Truffle (a developer tool), need to periodically check if blocks, and therefore transactions, that have been submitted have since been added to the blockchain. The is the duration of time between one such check and the next. polling interval It thus makes sense to optimise the efficiency of the client application by configuring a polling interval that is with the anticipated block interval. Drawing upon the concept of (in Nyquist–Shannon sampling theorem), it makes sense to pick a 15 second polling interval when anticipating a 30 second block interval from RSK. Manual testing appears to indicate that this works well. commensurate critical frequency Note that Truffle's default is a 4 second polling for an anticipated 15 second block interval on Ethereum. This is still "allowed", as critical frequency as that specifies the of the sampling to be . Configuration values should be picked carefully by weighing the pros and cons of performance against resource intensity. upper bound half Note that Truffle's implementation has 2 separate polling intervals: one for , which is for "regular" usage, and provider.pollingInterval another for , which is used exclusively for deployments (truffle migrate) deploymentPollingInterval These configuration options were originally not implemented, and were set to hard coded defaults. These were added specifically top be able to support networks with a different block interval! Configuring Truffle With all the above in mind, let's now see how to implement this in a Truffle project. In your file: truffle-config.js (1) Set a variable to contain a valid BIP-39 mnemonic phrase testnetSeedPhrase (2) Set a variable to contain the gas price you wish to use denominated in Wei. gasPriceTestnet (3) In the exported object, set the value of to be the following. config config.networks.testnet testnet: { : HDWalletProvider({ : { : testnetSeedPhrase, }, : , pollingInterval: , }), network_id: , : gasPriceTestnet, : , : , deploymentPollingInterval: , }, provider => () new mnemonic phrase providerOrUrl 'https://public-node.testnet.rsk.co/' // Higher polling interval to check for blocks less frequently 15e3 // Ref: http://developers.rsk.co/rsk/architecture/account-based/#chainid 31 gasPrice networkCheckTimeout 1e6 timeoutBlocks 100 // Higher polling interval to check for blocks less frequently // during deployment 15e3 (4) Now you can run sub-commands with this network selected, for example: truffle truffle migrate --network testnet That's it!
