Introduce Runtime Events #607

gavofyork · 2018-08-26T09:00:16Z

Based on #570

Runtime events are roughly equivalent to "Events" in Ethereum ABI model. They're high-level notifications for particular conditions hit by the runtime. Examples of such conditions might be a session rotation or a slash. When emitted, they can take arguments to further describe the event; an example for a Slash event would be the validator ID (AccountId) and the amount slashed (Balance).

Substrate has no specific means of encoding events into the block header like Ethereum's TransactionReceipt. Rather records of events are collated by the System and Executive modules so they form a vector of EventRecords (which includes metadata of the event; right now that's just which extrinsic that caused it to be emitted) and left in storage. An API is exposed from the runtime to query this storage item and return the events during the block. The storage item is cleared during the initialisation of the following block.

It is assumed that middleware or a client module on the node side will query new blocks and populate an indexed database with each block's events. Since the event records are stored as a simple storage item, light-clients can track and monitor events in a brute-force fashion. However in this PR, no effort is made to index events into storage to make the monitoring of specific parameters efficient for light-clients. Further consideration is required and can be introduced at a later stage.

Events are introduced into the runtime in much the same way as dispatching. Each module that wants to be able to deposit events exposes an Event type, usually an enum, which must implement Encode, Decode, Clone, Eq and Debug. The module's configuration trait is required to be given an "outer" Event type which allows the module's type to be converted Into the event type expected by the system module's deposit_event function (which is the same as the "outer" event type, but we assume a From relationship to avoid a cyclic type dependency). This was the most ergonomic, least round-about way I could find of getting the job done.

In the runtime, a new macro is used impl_outer_event! which is passed each of the modules that emit events and creates a "super-enum" type that each of the types can be converted Into. This type is then passed into each module's configuration trait as the outer event type.

Yet to do:

Unit tests.
Integration style tests.
Light-client friendly event indexing (i.e. index events into storage according to their parameters). Another PR.

New slashing mechanism (#554) … * Slashing improvements - unstake when balance too low - unstake after N slashes according to val prefs - don't early-terminate session/era unless unstaked - offline grace period before punishment * Fix warning * Cleanups and ensure slash_count decays * Bump authoring version and introduce needed authoring stub * Rename * Fix offline tracker * Fix offline tracker * Renames * Add test * Tests * Tests. Remove accidental merge files. Merge remote-tracking branch 'origin/master' into gav-new-pos Version bump, fixes (#572) … * Bump version, don't propose invalid blocks * Fix build. * Fixes. * More fixes. * Fix tests. * Fix more tests * More tests fixed Fix merge Fix accidental merge bug Fixes. Staking failsafes … - Don't slash/unstake/change session when too few staking participants - Introduce set_balance PrivCall Make minimum validator count dynamic. test fixes Fix tests. Fix tests Fix tests, update readme. Merge remote-tracking branch 'origin/master' into gav-new-pos Test with release. Use safe math when dealing with total stake Fix test again. Introduce events into runtime. Fix tests Add events for account new/reap Integration-style tests for events.

pepyakin

Looks great!

pepyakin · 2018-08-27T16:23:52Z

substrate/runtime/staking/src/lib.rs

-		T::OnAccountKill::on_account_kill(who);
+
+		// TODO: rename this to on_free_account_kill or some such, since it only pertains to removing the 
+		// free-balance part of the account, not the whole thing. 


I guess this is sorted now?

pepyakin · 2018-08-27T16:36:14Z

substrate/runtime/primitives/src/traits.rs

+impl<T> Convert<T, ()> for Empty {
+	fn convert(_: T) -> () { () }
+}
+pub struct UseInto;


How these are expected to be used? I can't see these used anywhere

pepyakin · 2018-08-27T16:39:00Z

README.adoc


-Substrate chains have two distinct features that make them "next-generation": a dynamic, self-defining state-transition function and a progressive consensus algorithm with fast block production and adaptive, definite finality. The STF, encoded in WebAssembly, is known as the "runtime". This defines the `execute_block` function, and can specify everything from the staking algorithm, transaction semantics, logging mechanisms and governance procedures. Because the runtime is entirely dynamic all of these can be switched out or upgraded at any time. A Substrate chain is very much a "living organism".
+Substrate chains have three distinct features that make them "next-generation": a dynamic, self-defining state-transition function, light-client functionality from day one and a progressive consensus algorithm with fast block production and adaptive, definite finality. The STF, encoded in WebAssembly, is known as the "runtime". This defines the `execute_block` function, and can specify everything from the staking algorithm, transaction semantics, logging mechanisms and procedures for replacing any aspect of itself or of the blockchain's state ("governance"). Because the runtime is entirely dynamic all of these can be switched out or upgraded at any time. A Substrate chain is very much a "living organism".


Can we expand what is STF little earlier, like a dynamic, self-defining state-transition function (STF)?

Yeah the docs is a WiP; I'll continue working on it, but I figured it's better to have something there sooner than later.

svyatonik

Just one overall question - are we ever going to allow custom contracts to access 'system' runtime modules.
Like if there'll be some contract that will be able to call public functions from System module, it could execute code like that to clear previous events:

let new_header = System::finalise();
System::initialize(new_header.number, new_header.parent_hash, new_header.extrinsics_root); // clear events
System::note_finished_extrinsics(); // 'simulate' exrinsic#0 execution

gavofyork · 2018-08-28T09:39:10Z

In reality all runtime code is trusted. There's no need to call into system module to clear or change events - you could just alter storage directly with the runtime_io module. The smart-contract sandbox is the only way of ensuring that (untrusted) code can't do stuff like clear bits of storage.

* master: Contracts: Per block gas limit (#506) Make sure to ban invalid transactions. (#615) (#620) Forward-port BFT fixes from v0.2 and restructure agreement cancelling (#619) Allow specifying listening multiaddresses (#577) Introduce Runtime Events (#607) update substrate/extrinsic-pool (#616) add a new unit test for extrinsic pool (#611) set the current repo in Cargo.toml (#610) add cli for purge chain (#609)

* WIP use scale-decode * Use scale-decode for event decoding and other optimising in that area * comment tweaks * samll optimisation on as_event fn

gavofyork added the A0-please_review Pull request needs code review. label Aug 26, 2018

gavofyork added this to To Do in Runtime via automation Aug 26, 2018

gavofyork added this to the PoC-3 (AFG) milestone Aug 26, 2018

gavofyork force-pushed the gav-events branch from 2154395 to 8000e9b Compare August 27, 2018 15:21

gavofyork requested review from pepyakin and svyatonik August 27, 2018 15:23

pepyakin approved these changes Aug 27, 2018

View reviewed changes

pepyakin added A8-looksgood and removed A0-please_review Pull request needs code review. labels Aug 27, 2018

svyatonik approved these changes Aug 27, 2018

View reviewed changes

Remove old code

0993a9a

gavofyork merged commit 221b7e1 into master Aug 28, 2018

Runtime automation moved this from To Do to Done Aug 28, 2018

gavofyork deleted the gav-events branch August 28, 2018 11:11

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce Runtime Events #607

Introduce Runtime Events #607

gavofyork commented Aug 26, 2018 •

edited

pepyakin left a comment

pepyakin Aug 27, 2018

pepyakin Aug 27, 2018

pepyakin Aug 27, 2018

gavofyork Aug 28, 2018

svyatonik left a comment

gavofyork commented Aug 28, 2018


		Substrate chains have two distinct features that make them "next-generation": a dynamic, self-defining state-transition function and a progressive consensus algorithm with fast block production and adaptive, definite finality. The STF, encoded in WebAssembly, is known as the "runtime". This defines the `execute_block` function, and can specify everything from the staking algorithm, transaction semantics, logging mechanisms and governance procedures. Because the runtime is entirely dynamic all of these can be switched out or upgraded at any time. A Substrate chain is very much a "living organism".
		Substrate chains have three distinct features that make them "next-generation": a dynamic, self-defining state-transition function, light-client functionality from day one and a progressive consensus algorithm with fast block production and adaptive, definite finality. The STF, encoded in WebAssembly, is known as the "runtime". This defines the `execute_block` function, and can specify everything from the staking algorithm, transaction semantics, logging mechanisms and procedures for replacing any aspect of itself or of the blockchain's state ("governance"). Because the runtime is entirely dynamic all of these can be switched out or upgraded at any time. A Substrate chain is very much a "living organism".

Introduce Runtime Events #607

Introduce Runtime Events #607

Conversation

gavofyork commented Aug 26, 2018 • edited

pepyakin left a comment

Choose a reason for hiding this comment

pepyakin Aug 27, 2018

Choose a reason for hiding this comment

pepyakin Aug 27, 2018

Choose a reason for hiding this comment

pepyakin Aug 27, 2018

Choose a reason for hiding this comment

gavofyork Aug 28, 2018

Choose a reason for hiding this comment

svyatonik left a comment

Choose a reason for hiding this comment

gavofyork commented Aug 28, 2018

gavofyork commented Aug 26, 2018 •

edited