Added cardano connector plugin #1636
Conversation
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1636 +/- ##
========================================
Coverage 99.95% 99.96%
========================================
Files 337 340 +3
Lines 29504 30120 +616
========================================
+ Hits 29492 30108 +616
Misses 8 8
Partials 4 4 ☔ View full report in Codecov by Sentry. |
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
| Address string `json:"address"` | ||
| } | ||
|
|
||
| var addressVerify = regexp.MustCompile("^addr1|^addr_test1|^stake1|^stake_test1") |
There was a problem hiding this comment.
This is just used for (extremely simple) address validation. Cardano uses bech32 addresses with a conventional set of HRPs, but I wanted to avoid pulling in a bech32 decoder, so I allowlisted the conventional HRPs instead.
| func (c *Cardano) DeployContract(ctx context.Context, nsOpID, signingKey string, definition, contract *fftypes.JSONAny, input []interface{}, options map[string]interface{}) (submissionRejected bool, err error) { | ||
| body := map[string]interface{}{ | ||
| "id": nsOpID, | ||
| "contract": contract, | ||
| "definition": definition, | ||
| } | ||
| var resErr common.BlockchainRESTError | ||
| res, err := c.client.R(). | ||
| SetContext(ctx). | ||
| SetBody(body). | ||
| SetError(&resErr). | ||
| Post("/contracts/deploy") | ||
| if err != nil || !res.IsSuccess() { | ||
| return resErr.SubmissionRejected, common.WrapRESTError(ctx, &resErr, res, err, coremsgs.MsgCardanoconnectRESTErr) | ||
| } | ||
| return false, nil | ||
| } | ||
|
|
There was a problem hiding this comment.
I don't see the signing key being used
There was a problem hiding this comment.
That's right. The "smart contracts" we're running in the cardano connector are offchain wasm components, nothing is actually published to the chain when you deploy a contract.
There was a problem hiding this comment.
okay need to understand this a bit better
There was a problem hiding this comment.
Was the offline chat enough to explain why we don't need the signing key here?
| func (c *Cardano) GenerateErrorSignature(ctx context.Context, event *fftypes.FFIErrorDefinition) string { | ||
| // TODO: impl | ||
| return "" | ||
| } |
There was a problem hiding this comment.
Would be interested to understand more how errors are reported in Cardano from smart contract
There was a problem hiding this comment.
The cardano smart contract doesn't report errors right now, only events. I don't understand the difference between errors and events, and I couldn't find any code in other plugins which streamed errors from the connector.
I've copied the "event signature" code into this function, but that's just a guess at what it's supposed to do. I'd want to see how consumers actually use events to be more confident about that.
| if !isBatch { | ||
| var receipt common.BlockchainReceiptNotification | ||
| _ = json.Unmarshal(msgBytes, &receipt) | ||
|
|
||
| err := common.HandleReceipt(ctx, "", c, &receipt, c.callbacks) | ||
| if err != nil { | ||
| l.Errorf("Failed to process receipt: %+v", msgTyped) | ||
| } | ||
| } |
There was a problem hiding this comment.
I see that this is heavily inspired from FFTM and the evm plugin - I would recommend in the future moving to a durable event stream here where the receipts have to be ack'd back as part of a batch.
There was a problem hiding this comment.
I was using EVM, Tezos, and FFTM as references for how the eventstream is supposed to work (trying my best to make Cardano match the semantics of other connectors). It looked like other connectors assume that every message in a batch is an event, not a receipt.
I think it makes sense to use resilient ack-ing for everything, but I'm a little wary about inventing semantics for it in this plugin that nothing else is using.
There was a problem hiding this comment.
Agreed - probably as a follow up. I'm building a framework at moment to allow for resilient ack-ing and get confirmation from FireFly core it has processed things correctly
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: Simon Gellis <[email protected]>
Proposed changes
Adds a cardano connector plugin to firefly core. This connector interacts with the firefly-cardanoconnect service from firefly-cardano.
Types of changes
Please make sure to follow these points
< issue name >egAdded links in the documentation.Other Information
The Cardano connector and implementation is still a work in progress; in particular we need documentation and tests. However, it works well enough to demo, and I'd like to merge this relatively soon so that people can run it without building firefly-core from a branch, or downloading an image from a private repo.