fetchEvents for LocalBlockchain

[Trivo25]

Description

This is the first part of extending LocalBlockchain to support fetchEvents and later in a second PR fetchSequenceEvents.

Under the hood

A smart contract can emit events

@method emitMe(value: Field) {
	this.emit("someEvent", value);
}

but the LocalBlockchain did not store emitted events until now. After the transaction has successfully been applied to the Ledger via applyJsonTransaction, all events are stored in a variable events. Events are identified by publicKey and tokenId.

LocalBlockchain now exposes a closure fetchEvents(), which returns all events that have been emitted.

The SmartContract class has been extended by adding a new method fetchEvents(start: UInt32, end?: UInt32): { type: string; event: AsFieldElements<any> }[], which returns a list of all events that have been emitted by a SmartContract instance, using the tokenId and publicKey as identifier and start and end as range options.

Note: There has been a discussion regarding what type to use in order to filter events. I went with using slots as an indicator for now.

Example

Developers can now call the fetchEvents(start: UInt32, end?: UInt32) method on an instance of a smart contract that uses the LocalBlockchain as active instance.

class MyApp extends SmartContract {
	
	events = {
		someEvent: Field,
	};

	@method emitMe() {
		this.emit("someEvent", Field.zero);
	}
}

// ...

let events = myAppInstance.fetchEvents(UInt32.from(0))
console.log(events)
/*
[
	{ type: "someEvent", event: Field(0)  }
]

*/

[Trivo25]

It would probably be smarter to set new events at the beginning of the array instead of the end (reverse). How is it enforced on the protocol level/archive api?

[mitschabaude]

hmm, not sure what's better to use 🤔 yeah we should probably mirror whatever the graphql API ends up doing

[mitschabaude]

nice work on your first PR! left a couple of suggestions

[ymekuria]

Nice work Florian! I left some comments.

[ymekuria]

We had a discussion awhile back about adding a static from method that invokes the original constructor instead of overriding the constructor in examples to encourage this pattern. Here is the discussion for background and here is an example.

What you are doing works (passing constructor arguments to super) but we want to encourage the .from pattern to the community. @mitschabaude do you still think we should encourage this .from pattern in our examples?

[mitschabaude]

Uhm, to be honest, I'm not sure. I think it's fine either way. My original idea was that you'd have to do nothing and use the generic constructor. .from would've only been for the few cases where you'd want to transform the input arguments. However, by now I think a constructor like this, which is a no-op, is still nice to add, because it becomes properly typed

[ymekuria]

That works for me. I'm fine leaving it as is if we are in agreement.

[mitschabaude]

return events?.[publicKey.toBase58()]?.[Ledger.fieldToBase58(tokenId)] ?? []

😉

[Trivo25]

ahh, perfect

[MartinMinkov]

Nothing to add that others haven't said for feedback, approving preemptively!
Great job! :D