-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Shelley TransactionLayer
#1673
Conversation
-- without converting from @SlotId@. | ||
let epochLength = EpochLength 1215 | ||
|
||
let Cardano.TxUnsignedShelley unsigned = Cardano.buildShelleyTransaction |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nicer to use signTransaction
.
But I thought the way cardano-crypto carries an encrypted XPrv and a password to the very end was intentional for… some security reasons? To construct SignKeyDSIGN
we'd need to provide the unencrypted key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was intentional for… some security reasons
Partly. Having key encrypted in-memory was an explicit request from the previous development team which was several times depicted as useless by cryptographers. What matters is storing them encrypted (cf the wallet-chain-libs rust implementation). We still use cardano-crypto for lack of alternative.
aa5ac1a
to
5360a16
Compare
646cd23
to
c066371
Compare
2183848
to
a3df4c1
Compare
84e9ee4
to
32c2475
Compare
094c617
to
2145ca1
Compare
We could split this if desired, but I think it should be manageable. |
lib/core/src/Cardano/Wallet/Primitive/AddressDerivation/Shelley.hs
Outdated
Show resolved
Hide resolved
let certs = [] | ||
|
||
-- TODO: The SlotId-SlotNo conversion based on epoch length would not | ||
-- work if the epoch length changed in a hard fork. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although, the transaction itself would be invalid before the hard-fork. True that, subsequent hardfork after shelley may be a risk but for Byron
-> Shelley
, there's no problem here if we know the new epoch length prior to the hardfork.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
era Byron | Shelley
el 3 | 2
epoch 0 1 2 3
=========================================
slot 0 |0 3 6 8
V 1 |1 4 7 9
2 |2 5
If we are here given a correct SlotId 3 1
at SlotNo 9
(which arguably would be unlikely, since there's a similar conversion to create the SlotId)
The we cannot simply convert back to SlotNo
using the genesis epoch length (here 3):
(SlotNo 3*3+1) == (SlotNo 10)
But the correct answer is: SlotNo 9
|
||
-- TODO: The SlotId-SlotNo conversion based on epoch length would not | ||
-- work if the epoch length changed in a hard fork. | ||
let timeToLive = (toSlotNo epochLength slot) + 7200 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
7200 ? Avoid magic numbers, make it a named constant and explain the rationale of choosing 7200
(ultimately, we want that configurable via the API). Can you make sure to let Alex know about this?
-- Maybe that value wasn't taking delegation keys into account? | ||
-- | ||
-- Regardless: | ||
-- TODO: Implement properly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The length of the output will actually depend on the value and the type of addresses used. We can assume worst-case scenario which are currently 65 bytes for addresses indeed. 32 bytes for just the value sounds huge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work. I think we can go with this first big chunk and do improvements / additions on top.
bors try |
tryBuild failed |
Useful for playing around
To make it work on shelley, without relying on that the minFee is accurate.
- split functions out so that they read better and will likely be re-used for implementing other parts of the transaction layer. - avoid unnecessary identifiers declaration. Too many identifiers in a single small context don't make things more readable. - changed a few types to avoid repeating the same unwrapping operation - named some in-place calculation (like realFee) - used forM + pattern-matching instead of mapM and pointfree style. Pointfree is usually not readable when it's in a context with more than one line
And tweak calculation
The fee calculation isn't actually made on the transaction size in bytes, but rather, on an abstract representation of the transaction. This is detailed in the ledger specifications and implemented in the cardano-ledger-specs module. So, we might as well re-use this here.
…erated on the fly
bdd431c
to
3c1d508
Compare
By not depending on a pass to the next epoch, which can be quite long on the cardano-node.
dbd08da
to
406bfa2
Compare
I force pushed the "regenerate nix" commit like a retard. :| |
bors r+ |
Build succeeded |
Issue Number
#1672
Overview
toCardano
conversion functions interacting withcardano-api
TransactionLayer
and enabledWallet
andTransaction
integration tests.Comments
Main commit: 4f6ea17