Skip to content
This repository has been archived by the owner on May 13, 2022. It is now read-only.

Support custom transaction validation code #1482

Open
bzp99 opened this issue Apr 12, 2021 · 1 comment
Open

Support custom transaction validation code #1482

bzp99 opened this issue Apr 12, 2021 · 1 comment

Comments

@bzp99
Copy link
Contributor

bzp99 commented Apr 12, 2021

We would like to use Burrow in an environment where Burrow runs as a side chain and to a ‘main’ blockchain and the provider of the main chain would want to enforce (or simply audit) some conditions on the transactions (actually smart contract calls) on the side chain. One way to achieve this would be to have their own node within the side chain that runs their custom validation code on all transactions. Or they may want to force all side chain nodes to run their validation code.

The idea is to include running some pluggable validation code in Burrow.

What point in Burrow’s operation would be a good place to do this?

I was thinking since Burrow uses Tendermint for consensus, this feature could be implemented at the point where Burrow checks whether a block (=> its transactions) is valid in the Prevote step. In addition to whatever validation code runs there (so far I was unable find this in Burrow’s source code; I found some validation code in execution/execution.go but I am not sure this is where to look), Burrow would also run some custom validation code.


As to how to implement pluggable validation code, a simple solution would be to use Go plugins, similar to how Fabric does it. I coded a primitive proof-of-concept kind of thing at bzp99@ed3b045

Now I would like to improve on this by pulling the code out of the execution module into a new one and possibly moving the logic that runs the pluggable endorsement code to where it belongs (where Burrow validates blocks in Prevote).

@silasdavis
Copy link
Contributor

Some questions:

  1. Can this additional validation be handled at a smart contract level? If not, why not?

  2. Does:

the main chain would want to enforce

Imply the main chain has to process transactions in on the side chain via the endorser module or are they just providing additional static rules to be loaded as a plugin? If the former then doesn't this defeat any scaling benefit? If the latter then question 2 again (possibly with some extension into the Burrow executor run time.

Burrow would also run some custom validation code.

What additional validation code, running where?


Custom validation logic could potentially be run here: https://github.com/hyperledger/burrow/blob/main/execution/execution.go#L224, as you have it in your prototype, if the endorsement was only relevant for CallTx then it could be added to CallContext

That is called on CheckTx and also on DeliverTx - the difference being that we only run lightweight checks (signatures, balances, etc) on CallTx when running CheckTx. Failing CheckTx means the tx is ejected from the mempool by nodes.


See also 'natives', e.g.: https://github.com/hyperledger/burrow/blob/main/execution/native/permissions.go which provides a framework for defining Go-based 'smart contracts'. Currently they are hard-coded by it would not be a massive leap to deploy them via plugins, which I had considered in the past. We also have WASM as a target.

In general my worry with plugins is it weakens rather than strengthens the verification story in Burrow, since you now have additional binary blobs provided as config to worry about, but ultimately we require trusting some binary so I suppose there is not a huge difference.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

2 participants