czareko / pallet-event-storage

Simple event storage with a limited lifetime

Pallet EventStorage

Simple event storage with a parametrized history size

The idea is to store custom events in our pallet, access to this functionality should be limited only to one predefined account. All events older than a configured period of time should be removed automatically.

This example is a tech representation of the idea because we didn’t focus on how to use these events. The first step to change it would be to redesign the CustomEvent struct

pallet-event-storage/src/lib.rs

Lines 20 to 27 in d83af49

	#[derive(Clone, Encode, Decode, PartialEq, RuntimeDebug, TypeInfo)]
	#[scale_info(skip_type_params(T))]
	pub struct CustomEvent<T: Config> {
	// This is a very tech example, to make it more useful from business perspective this should be the first place to expand.
	//pub time_stamp: i64, <<--- we have this as a key, but probably for more complex business operation we can need this inside as well.
	pub content: Vec<u8>,
	pub reporter: <T as frame_system::Config>::AccountId, //we limited access to our method so we could remove this from here as well.
	}

Parametrization

Parameter	Description
HistorySize: i64	History size defined in seconds
AuthorizedAccountId: AccountId	Basic account id privilaged to create custome events

Here we have a sample from mock.rs

pallet-event-storage/src/mock.rs

Lines 29 to 32 in d83af49

	parameter_types! {
	pub const HistorySize: i64 = 2; // Here we set up a short history size (in seconds)
	pub const AuthorizedAccountId: AccountId = 1;//Very basic idea for caller identity limitation
	}

How to test it?

The best description for the whole functionalities we will find in tests.rs

cargo test

What we could do better?

1. Caller verification

Now we have a very basic idea for this, but not as simple as using root as a caller. There are many good examples how to prepare this in the more advanced way. For example: pallet_sudo, pallet_membership, pallet_identity.

2. Storage

There are many ways how we could protect our storage better. For example, we could set a maximum number of items and a single item size. Access to the Storage should be limited as much as possible.

Frame V2 has good support for running the pallet in more than one instance, I don't see a business example of why we would like to do this with this pallet, but of course, if we have a serious need we could think about it.

3. Public methods

We have a few public methods in our pallet. We use them only for tests. The question is if we need them, or maybe it would be possible to organize this pallet in a different way to hide everything that is possible.

4. CustomEvent - structure

Now it's a completely tech representation. With more detailed business requirements, more needs can come. This could change our idea for the map key in our Storage and how we search history items.

5. CustomEvents vs Pallet Events

Now we generate simple system events after every method execution, but we don't know the external/integration requirements for this pallet, so in a serious example we should think about this part more.

6. Errors

Now Exception handling show that we know how to use them, but we should try to catch more negative behaviors.