(a) & (b) documents the current approach of our repository, where an app speaks web3 json-rpc to the underlying system, whether that be evmcc, or an eth node, such as geth
(c) documents the internals of what happens in the fab3 case, where the web3 json-rpc sendTransaction is converted internally and the output of fab3 is a fabric-signed transaction with a signature understandable by a fabric network, and once it arrives at the evmcc we use the incoming signed-ness to determine what eth-equivalent address is performing the transaction. https://github.com/hyperledger/fabric-chaincode-evm/blob/cc42f841d313ac6187cc3f63be588f57c8f1392a/evmcc/evmcc.go#L214
(d) is the requirement that must be fulfilled to send a raw transaction. The transaction must be fabric-signed before reaching fab3, which will pass it unchanged to evmcc, where the exact same process as in (c) will happen. This is difficult to perform right now, as the go-sdk does not support offline transaction signing.
(e) is my understanding of a metamask workflow, where the application is sending a standard transaction, and metamask is performing an offline signature to convert it to a raw transaction.
(f) is how we would require metamask or other intermediate proxies to support fabric-signatures in order to submit a raw transaction.
(g) Is similar to (f) with a more fabric oriented example
