Should we simplify the outcome format to make development easier?

[geoknee]

We currently support a mixture of assets. The format currently allows for different orderings and even repeated entries (which doesn't really make sense).

One suggestion is to require that outcomes have length one and are for the native asset. This would make a bunch of code easier to write, and we would only lose a small number of use-cases.

Relevant code:

go-nitro/channel/state/outcome/exit.go

Lines 155 to 171 in 7412bc6

	// easyExit is a more ergonomic data type which can be derived from an Exit
	type easyExit map[common.Address]SingleAssetExit
	// toEasyExit() convets an Exit into an easyExit.
	//
	// An EasyExit is a mapping from asset to SingleAssetExit, rather than an array.
	// The conversion loses some information, because the position in the original array is not recorded in the map.
	// The position has no semantic meaning, but does of course affect the hash of the exit.
	// Furthermore, this transformation assumes there are *no* repeated entries.
	// For these reasons, the transformation should be considered non-invertibile and used with care.
	func (e Exit) toEasyExit() easyExit {
	easy := make(easyExit)
	for i := range e {
	easy[e[i].Asset] = e[i]
	}
	return easy
	}

[lalexgap]

I personally find that multi-asset support adds another layer of complexity that makes thinking about the code slightly more challenging. When I talk or think about state channels I'm generally ignoring the idea of multi assets. Also most of our tests assume the use a single asset, meaning that a lot of logic for multi-asset support is not fully tested.

If we can enforce single assets without too much effort and don't think multi-asset support is important for the initial version then I'd be in favour of it!

We could also go the other way and lean into multi-asset support by updating our test cases to use multi-asset outcomes. That would prevent us from having to debug multi-asset code we wrote today later on when we're serious about multi-asset support.

[andrewgordstewart]

I don't understand why we aim to support multi-asset outcomes at this time. We don't have a plan to take advantage of this support in this project, and it seems like a fairly reasonable amount of engineering effort is being put into supporting multi-asset outcomes.

Am I wrong to believe that single-asset outcomes would yield simpler data structures, clearer code, fewer tests, etc?

[geoknee]

Am I wrong to believe that single-asset outcomes would yield simpler data structures, clearer code, fewer tests, etc?

I don't think you are wrong. But we have to weigh the pros and cons. If there was no upside at all to supporting multi-assets, the decision would be easy. But I think there are some upsides:

1. Compatibility with our nitro-protocol npm package / typecript code.
2. We already have mult-asset support. We can't save the engineering effort that we have already spent, and it would actually take some more engineering effort to roll back to a single asset world.
3. Support for all the rich behaviour supported by the solidity "exit format" that we spent quite some time thinking about. This covers Ethereum's ERC20 tokens, Connext-style withdraw helpers, atomic swaps in a single state channel, and so on. These are arguably currently outside the scope of the Filecoin use case. But it seems quite likely to me that they may become part of that picture in time, if the FVM does indeed allow for full solidity support. Retrieval providers could well get paid in something other than FIL, especially when you consider the secondary market and all of the various economic models that could be dreamt up for that.

@lalexgap mentions that doubling down on multi asset support might involve expanding our test suite. But it might be a decent compromise to have the production code support multi assets while only being comprehensively tested for a single asset. This would mirror what we do with virtual funding -- the code supports n-hops but is only tested for a single hop. To me this is a reasonable way (in both cases) to allow for an upgrade path without putting in excessive work on a use case we don't currently need to support.

[andrewgordstewart]

We can still be compatible with nitro-protocol etc. and use a single-asset outcome. The choice to use a single asset-outcome can be a choice made by the engine/protocol internals of the go-nitro package, and not at the smart contract level!