Guillaume Thiolliere
Guillaume Thiolliere
> Overall logic looks okay, however IMO this statement store logic is blowing up the service instantiation quite a bit, what do you think about moving the statement store instantiation...
> In hindsight I think we should have gone with a disabled-by-default CLI flag. Whe original argument against that was that people might forget to enable it for the people...
ok, this is now written with a new cli arg: `--enable-statement-store`. which is false by default. I still wish to have it in the upcoming release but maybe people will...
Would it be better to roll this without breaking change? because there is now already some code using those RPC, I think adding new RPC is not a problem no?
In general transactions the transaction extension typically contains signature as extra. How do we expect to request this signature? Typically the equivalent of a signed transaction is a general transaction...
I see, so for transaction extensions containing signatures, the caller will send those extensions with invalid transaction e.g. 0x000.. , then the implementer will override the caller "preference", or omit...
ok, I may be wrong but I worry not sending the transaction extension as a mean to let the `Implementer` fill it may not be fine-grained enough and potentially ambiguous....
OK I understand the goal and scope now, and it looks very good. This abstract other the creation of transaction, allowing dapps to only send their intention: most of the...
/cmd prdoc --audience node_user node_dev runtime_dev --bump minor
/cmd prdoc --audience node_dev runtime_dev --bump minor