Testing Plan for the Ethereum Chain Abstraction

[rauljordan]

Background

In this repository, we designed a chain abstraction the validator client code which allows the validator to interact with the protocol smart contracts in an idiomatic, simple manner that does not expose Ethereum's internals. The validator simply has access to an interface that looks like this:

// ChallengeManager allows for retrieving details of challenges such
// as challenges themselves, vertices, or constants such as the challenge period seconds.
type ChallengeManager interface {
	Address() common.Address
	ChallengePeriodSeconds(ctx context.Context) (time.Duration, error)
	CalculateChallengeHash(ctx context.Context, itemId common.Hash, challengeType ChallengeType) (ChallengeHash, error)
	CalculateChallengeVertexId(ctx context.Context, challengeId ChallengeHash, history util.HistoryCommitment) (VertexHash, error)
	GetVertex(ctx context.Context, vertexId VertexHash) (util.Option[ChallengeVertex], error)
	GetChallenge(ctx context.Context, challengeId ChallengeHash) (util.Option[Challenge], error)
}
... // More interfaces for challenge vertices, challenges, etc.

Underneath the hood, the implementation of this interface will make actual Ethereum transactions, check for their confirmation, receipts, and retry if possible. It will take care of estimating gas and paying tx fees via tx opts as needed.

However, we have only tested this so far with a simulated geth backend, which can be programmatically advanced and does not represent a real scenario. A real validator will be using the chain abstraction with a JSON-RPC or IPC backend, in which disconnects can happen, latency can play a role, txs can fail, and more.

Our goal is to have confidence our chain abstraction implementation works with a real JSON-RPC or IPC backend. This issue outlines a plan to get us there and how we can test out different scenarios to up our confidence.

Setting Up

We have existing code that sets up an Ethereum simulated backend with a few genesis accounts seeded with funds. Under https://github.com/OffchainLabs/challenge-protocol-v2/blob/a55f3547f3ef7ebe051b4ed5881f9928a8b4fb73/validator/deploy_rollup_test.go#L342

// Represents a test EOA account in the simulated backend,
type testAccount struct {
	accountAddr common.Address
	txOpts      *bind.TransactOpts
}

func setupAccounts(t testing.TB, numAccounts uint64) ([]*testAccount, *backends.SimulatedBackend) {
	t.Helper()
	genesis := make(core.GenesisAlloc)
	gasLimit := uint64(100000000)

	accs := make([]*testAccount, numAccounts)
	for i := uint64(0); i < numAccounts; i++ {
		privKey, err := crypto.GenerateKey()
		require.NoError(t, err)
		pubKeyECDSA, ok := privKey.Public().(*ecdsa.PublicKey)
		require.Equal(t, true, ok)

		// Strip off the 0x and the first 2 characters 04 which is always the
		// EC prefix and is not required.
		publicKeyBytes := crypto.FromECDSAPub(pubKeyECDSA)[4:]
		var pubKey = make([]byte, 48)
		copy(pubKey, publicKeyBytes)

		addr := crypto.PubkeyToAddress(privKey.PublicKey)
		chainID := big.NewInt(1337)
		txOpts, err := bind.NewKeyedTransactorWithChainID(privKey, chainID)
		require.NoError(t, err)
		startingBalance, _ := new(big.Int).SetString(
			"100000000000000000000000000000000000000",
			10,
		)
		genesis[addr] = core.GenesisAccount{Balance: startingBalance}
		accs[i] = &testAccount{
			accountAddr: addr,
			txOpts:      txOpts,
		}
	}
	backend := backends.NewSimulatedBackend(genesis, gasLimit)
	return accs, backend
}

In that same file, we also have a function that deploys all the contracts necessary for our validator, called setupAssertionChains https://github.com/OffchainLabs/challenge-protocol-v2/blob/a55f3547f3ef7ebe051b4ed5881f9928a8b4fb73/validator/deploy_rollup_test.go#L41

This sets up N different chain abstraction instances for different sender addresses and deploys the contracts to a simulated backend. We can then use this test helper in our unit and integration tests to see assert things and check if validators can complete their moves during a challenge.

We will need to modify these helpers to instead use a real JSON-RPC connection to a backend or middleware

Testing Plan

The testing plan is to get our integration test, https://github.com/OffchainLabs/challenge-protocol-v2/blob/a55f3547f3ef7ebe051b4ed5881f9928a8b4fb73/validator/challenges_test.go#L35 to succeed using a real backend. Once we can get this test passing, then we want to check the following scenarios:

• Validators can resolve their challenges eventually even if a few RPC disconnects happen along the way
• Validators can resolve their challenges even if some of their txs fail
• Tx taking a long time don't cause serious issues, or perhaps we could have a timeout configured in the chain abstraction logic
• Chain abstraction is able to retry txs if they fail
• Chain abstraction is able to bump gas if a tx is failing
• Chain abstraction should perhaps use different sources for gas estimation?
• Chain abstraction could support multiple endpoints for fallback?

We might need some kind of proxy middleware that can drop txs or return failing statuses to see how the chain abstraction reacts in certain situations.

It is important to check Nitro to see what utilities we could bring over that can help us with some of the tasks above. For example, we already have access to utilities from Nitro that can wait for tx approval, but perhaps we need configurable timeouts. See here https://github.com/OffchainLabs/challenge-protocol-v2/pull/139/files#diff-c139bee8ba652403c1659d38f5951fe9a2b2cdb2eea168135484224efc1a2cabR455 for the utilities added in earlier. Some of these have been removed since, so we need to consider adding them back