Path to the bcc-node config file (e.g. to bcc-node projectconfigurationbcc/mainnet-config.json)

The environment and initial ledger state

The environment returned by initialLedgerState

The current ledger state

Some block to apply

The new ledger state (or an error).

True to validate

Path to the bcc-node config file (e.g. to bcc-node projectconfigurationbcc/mainnet-config.json)

This is needed for the number of slots per epoch for the Cole era (on mainnet that should be 21600).

Path to local bcc-node socket. This is the path specified by the --socket-path command line option when running the node.

The initial accumulator state.

Accumulator function Takes:

• Environment (this is a constant over the whole fold).
• The Ledger state (with block i applied) at block i.
• Block i.
• The accumulator state at block i - 1.

And returns:

• The accumulator state at block i

Note: This function can safely assume no rollback will occur even though internally this is implemented with a client protocol that may require rollback. This is achieved by only calling the accumulator on states/blocks that are older than the security parameter, k. This has the side effect of truncating the last k blocks before the node's tip.

The final state

Initial ledger state

A client to wrap. The block is annotated with a 'Either Text LedgerState'. This is either an error from validating a block or the current LedgerState from applying the current block. If we trust the node, then we generally expect blocks to validate. Also note that after a block fails to validate we may still roll back to a validated block, in which case the valid LedgerState will be passed here again.

A client that acts just like the wrapped client but doesn't require the LedgerState annotation on the block type.