You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 13, 2022. It is now read-only.
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).
The text was updated successfully, but these errors were encountered:
Can this additional validation be handled at a smart contract level? If not, why not?
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.
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 freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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).The text was updated successfully, but these errors were encountered: