Partial overwrite of ABCI possible?

[faustbrian]

I'm currently working on an idea that doesn't require a full ABCI replacement because I'm only interested in replacing/intercepting the checkTx and deliverTx methods to make sure transactions are properly validated.

The way I have it currently implemented is that I have an ABCI server in TypeScript that intercepts the aforementioned methods. The ones that don't need any modifications are forwarded to the Go ABCI because no behavioural changes are necessary. This is rather tedious to do because the JS ABCI is outdated and even using the latest proto files there are some issues with those.

An idea I had to simplify this and make it more stable was to run a modified Go ABCI that alters how CheckTx and DeliverTx are implemented by having them execute a call to a node.js binary that validates the given input. This would mean there is only a single ABCI server running rather than 2 like the case is right now, the TS ABCI for interception and forwarding and the Go ABCI for actual processing in the end.

Are there any better solution than those scenarios if you need to only partially replace ABCI methods in another language rather than reimplementing the full ABCI server?

[creachadair]

In general, consensus will not work if the application does not implement all the ABCI methods, so you'll need to either implement or delegate all the methods. Beyond that, a good answer will depend on what problem you're trying to solve by intercepting these calls. If that intent is merely to extend an existing application (e.g., one written in Go), you're likely to have an easier time writing the extension in that language, forking and/or wrapping the existing application code directly and building a new version.

It's also worth considering the eventual deployment scenario for such a shim. As a node operator, my first question would be why I'd want to add an additional independent layer, rather than updating the application itself to implement the desired behaviour.

As a rule, intercepting the connection between the application and the consensus node should be done with great caution: It would be easy for such a shim to introduce incorrect or malicious behaviour. Even with no ill-intent, changing what the app or consensus sees as "ground truth" could cause a node to appear broken or corrupt (possibly leading to penalties from the rest of the network).