R&D how blockchains with custom logic can do so with less copied Rivine code

[GlenDC]

Thanks to the introduction of the RivineCG tool, generating a new Rivine blockchain became very easy and almost non-technical, even allowing the use of optional extensions for minting and authentication of addresses used in coin transfers.

The following chains are currently chains entirely generated by RivineCG:

• EuroChain
• ThreefoldBonusChain
• FreeFlowChain

However, it is currently TFChain is not generated yet, and GoldChain is only generated. Therefore:

• investigate how chains can inject custom extensions:
  • including consensus plugins
  • CLI commands
  • HTTP API endpoints
• currently it is already possible to overwrite CLI sub commands on a category level (e.g. all wallet commands, all explorer commands, ...), as this is required for chains that require custom logic in existing functionality provided by Rivine. However, often this customisation is only required for specific subcommands of that category and not all of them, so it would be great if we could make that customisation, optionally, even more granular;
• modules such as the wallet module, are currently too much written as one big black box, therefore a refactor of that module needs to be investigated, allowing others to provide their own wallet module, without requiring all code to be copied. Ideally it also allows Go-written light clients to not have to reinvent the wheel for everything
  • tracked as issue R&D wallet module design and possible refactor #614
• investigate any other reason why currently GoldChain/TFChain have copied Rivine code in their codebase and how this can be potentially avoided or at the very least reduced;

[GlenDC]

Other code modified/overwritten/copied:

• 🛑 frontend explorer code (goldchain/tfchain):
  • 🙏 This one is hard to avoid with the plainjs code. Given that there is no way to inject any custom logic into it. If all is done well, the modern Vue explorer (see Use modern (vuejs) explorer for rivine example chain #607 and linked issue) should allow a custom frontend explorer without having to copy all code, and instead work with common components and libraries to do the heavy lifting for you, and even help you with writing your custom logic);
• ⚠️ daemon cmd: daemon.go (goldchain/tfchain):
  • Not sure this is too bad, the code is pretty limited and it is where all the different parts are plugged in. Even so it might be worth looking into why the daemon.go code is ovewritten specifically ⁽¹⁾.
• ⚠️ client cmd: client files (goldchain/tfchain):
  • very similar reason as the daemon code, but than on the client (CLI) side. Again not too sure if bad, but in an analog manner it wouldn't hurt to list the reasons why these code files are modified by hand and see if we can automate that in the template somehow ⁽²⁾;
• ✅ HTTP API (RESET) endpoints (goldchain/tfchain):
  • this is already done neatly I think, given that only the endpoints that are desired can be overwritten while the other ones can be used directly from the Rivine api pkg.
  • ⚠️ we'll need to make it just as easy to make it possible to modify/extend the API when we start supporting GraphQL as is planned in R&D issue provide GraphQL explorer module for rivine (shorthand: q) #612 (driven from story R&D merge of explorer/consensus modules #605);
• 🛑 CLI client commands (goldchain/tfchain) already have been discussed in the main issue and definitely have to be made easier to overwrite!

All in all I am quite happy with the progress we already made. If you look at "custom" chains such as goldchain and tfchain, the actual amount of custom code is still quite small, compared to the entire Rivine codebase (And it deps) that drive it. We came a far way already it seems.

[GlenDC]

To continue from last comment (#606 (comment))...

---

(1)

daemon cmd: daemon.go (goldchain/tfchain)

The biggest reason is for the injection of custom extensions (whether it is the non standard but Rivine-developed ERC20 extension or a complete custom extension such as the custody-fee extension in goldchain or threebot extension in tfchain).

• This should be able to be done automatically by providing the template code required to inject as a file and be able to configure such custom extensions in the blockchain cfg file used by the RivineCG generator

In GoldChain there is also a second reason. That is, it requires the transaction pool upfront because it requires it for its HTTP Handler of its custom Custody Fee extension.

• This is probably resolvable by defining the order in which modules and extensions are loaded somehow.

In TFChain there is even a third reason. That is, it has its own Wallet module, that should be used instead of the regular wallet module.

• This can probably be fixed by the ability to overwrite the existing modules used in the daemon.go templated cod.

...

(2)

client cmd: client files (goldchain/tfchain):

Standard command (groups) that are overwritten, something the rivine cli pkg allows.

• Fixable by allowing these kind of things to be configured somehow, perhaps by providing extension template code files.

Registration of custom condition types, transaction versions.

• Fixable by allowing these kind of things to be configured somehow, perhaps by providing extension template code files.

Custom commands to be added.

• Fixable by allowing these kind of things to be configured somehow, perhaps by providing extension template code files.

[GlenDC]

I think there is a lot to be figured out on how to exactly provide the required capabilities addressed in the comments of this issue, but so far it does seem like most of the current overwritten code can be allowed to be configured and be provided as template extensions. It won't stop the need of writing custom logic (impossible to avoid anyhow), but it will at least not enforce an entire file to be copied and overwritten, still making it easy to keep as much of the codes central and more maintainable.