feat: add support for eth_getBlockReceipts

[virajbhartiya]

Related Issues

Fixes #12429

Proposed Changes

Implimented eth_getBlockReceipts method which accepts a block number and returns all the transaction receipts for it

Additional Info

QuickNode
Infura

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title conforms with contribution conventions
• Update CHANGELOG.md or signal that this change does not need it per contribution conventions
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[virajbhartiya]

As far as my understanding of deferred execution, it refers to the scheduling or delaying of actions within the Filecoin protocol in smart contracts or while processing messages. Also, Filecoin nodes maintain a replicated state machine, and state transitions may be deferred while validation of proofs or consensus confirmations haven't been met.

For chain forks, it occur when two or more valid blocks are mined at the same height but from different miners, creating divergent chains. I am still reading about the Expected Consensus mechanism but it chooses which fork to go forward with based on which chain has the highest aggregate power of the miners that have contributed to that chain.

[rvagg]

We're going to need to check this, does it produce what we want? I suspect not, you'll find out if you compare the output in the itests with EthGetTransactionReceipt I think.

there's a translation layer inside the event subsystem to go from id addresses to robust addresses, you can see it in action here:

lotus/chain/events/filter/event.go

Lines 104 to 114 in 9b86cc5

	if !found {
	var ok bool
	addr, ok = resolver(ctx, ev.Emitter, te.rctTs)
	if !ok {
	// not an address we will be able to match against
	continue
	}
	addressLookups[ev.Emitter] = addr
	}
	if !f.matchAddress(addr) {

The resolver itself is

lotus/node/modules/actorevent.go

Lines 134 to 147 in 9b86cc5

	AddressResolver: func(ctx context.Context, emitter abi.ActorID, ts *types.TipSet) (address.Address, bool) {
	idAddr, err := address.NewIDAddress(uint64(emitter))
	if err != nil {
	return address.Undef, false
	}
	actor, err := sm.LoadActor(ctx, idAddr, ts)
	if err != nil || actor.DelegatedAddress == nil {
	return idAddr, true
	}
	return *actor.DelegatedAddress, true
	},

You could just potentially use the resolver in EventFilterManager to do this, it's exposed as AddressResolver, just be sure to cache the look-ups like CollectEvents does because you're likely to have a lot of duplicates in a single set.

[rvagg]

you might need to check out the other uses of SimpleCoin to make sure you interact with it appropriately, I think we're failing here

[virajbhartiya]

inputData, err := hex.DecodeString("0000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000066162636465660000000000000000000000000000000000000000000000000000")
require.NoError(t, err)

// Invoke the sendCoin function to ensure there is a transaction
_, _, err = client.EVM().InvokeContractByFuncName(ctx, client.DefaultKey.Address, contractAddr, "sendCoin(address,uint256)", inputData)
require.NoError(t, err) // Ensure the function call is successful

Is this the correct implementation for it?

[aarshkshah1992]

Had a chat with @virajbhartiya and he will use the MultipleEvents contract to generate events here and test this out.

[virajbhartiya]

I was learning about Cid in IPFS, and from what I understand, it's a unique identifier created by hashing the contents of a file stored on IPFS. This makes the file immutable, as any change to the content generates a new Cid. IPFS uses the MultiHash protocol go generate a Cid. Cid functions as a content-based address, allowing nodes to locate the file on the network. It’s similar to how domain names function in web2, but instead of pointing to a location, it points directly to the data itself. Am I going in the right direction? @aarshkshah1992

[rvagg]

Getting very close I think!

fwiw you can run the itests locally but they're best done specifically targeted, e.g. go test ./itests/fevm_test.go -run TestEthGetBlockReceipts -v. It should be quick enough to run on most machines. You should try it out on the ones you're modifying to see how close you are. Currently I need to Approve and Run CI for you here as a first-time contributor, unfortunately.

[virajbhartiya]

I have made the changes suggested above, and also implemented MultipleEvents in the test, can you please give it a look @aarshkshah1992 @rvagg

[aarshkshah1992]

@virajbhartiya Merging this into a feature branch and taking it over to fill in the missing bits. Looks mostly good here.

Thanks for all your hard work here !