-
Notifications
You must be signed in to change notification settings - Fork 0
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
Full transaction format with signer integration #74
Conversation
Minimum allowed coverage is Generated by 🐒 cobertura-action against 578f520 |
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.
Some tests would be great
payload: kairos_tx::asn::SigningPayload, | ||
) -> Result<kairos_tx::asn::Transaction, CryptoError> { | ||
// Validate payload signature. | ||
let tx_hash = kairos_tx::hash(&payload).map_err(|_e| CryptoError::TxHashingError)?; |
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.
I think it would be great if all of these error types could take anything that is Debug
and one could be able to propagate the inner errors message. I.e. I want to see what exact hashing error happened. The one that _e.to_string()
would give me.
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.
Done in 0242e4c.
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.
I don't see a benefit to this CryptoSigner
trait. It should instead be replaced with a sign
and verify
generic function.
It also does too much at this point.
from_private_key_file
andfrom_public_key
should be removed and replaced withFrom
trait implementationsto_public_key
can be extracted to aFrom
trait implementation too.sign
andverify
could be extracted in a trait, but I would be surprised that there is nothing like this already somewhere.
Instead of all these steps, I would remove the CryptoSigner
trait completely, and implement a generic function that says "if these traits are implemented ..." I will produce either this signed result or an error.
sign_tx
could moreover be an alias for calling sign(tx.into())
. If the ASN1 type would have a respective From
trait implementation. And would moreover not require us to introduce a tx
feature.
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.
I would prefer if from_private_key_file
remain a method, not a From
impl.
I don't like From
/Into
doing IO.
I agree we don't need the CryptoSigner
trait, since there is only one implementation just keep the Signer
struct.
Currently this implementation signs transaction hashes.
I have my doubts about signing transaction hashes rather than transactions bodies.
It is more general, but I suspect it's a lot of overhead in a zkVM on simple transfer/withdraw payloads.
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.
I have my doubts about signing transaction hashes rather than transactions bodies.
You have to hash the input before signing; signing algorithms take 255-bit input (for secp256k1) or 256-bit input (for ed25519). See https://crypto.stackexchange.com/a/59203
#[non_exhaustive] | ||
pub struct Transaction { | ||
pub public_key: PublicKey, // NOTE: Field name can be different than defined in schema, as only **order** is crucial | ||
pub payload: SigningPayload, |
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.
I understand that you can compute the PayloadHash, I'm just wondering where the according computation happens? Or should it be added as a field here?
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.
Thanks for catching it, I forgot to add hash
field - added in 3003e72.
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.
Computing PayloadHash
happens in crypto module in sign_tx_payload(). This is the only safe method of constructing fully validated transaction.
kairos-tx/src/lib.rs
Outdated
} | ||
|
||
// Constructor for non-exhaustive transaction struct. | ||
pub fn make_tx( |
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.
I don't understand the purpose of this function. it is basically new
for a Transaction
type. Not saying it should be a new
.
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.
You are right. I replaced this helper with constructor in 52b2854.
Slightly off topic, but could we remove nonce from deposit? I have to do that anyway for the trie/risc0 encoding representation of transactions. |
…into feature/full-tx-format
Ready for re-review, tests are missing though. |
#[cfg(feature = "tx")] | ||
fn verify_tx(&self, tx: kairos_tx::asn::Transaction) -> Result<(), CryptoError>; | ||
#[cfg(feature = "tx")] | ||
fn sign_tx_payload( | ||
&self, | ||
payload: kairos_tx::asn::SigningPayload, | ||
) -> Result<kairos_tx::asn::Transaction, CryptoError>; | ||
|
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.
I don't love feature gated parts of traits.
Generally they should be separated out into a separate trait.
I also don't like having a trait with a single impl, but these issues can be addressed in followup at a much latter date.
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.
Created follow up task - #86.
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.
Let's merge
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.
Good code
Follow up task created - #87. |
This PR updates ASN.1 schema to compose full transaction data, and integrate Signer module with it.
Most importantly, this will unblock:
kairos-server
- Verify signatures #7.kairos-tx
with smart contract events #73.Transaction format
The following top-level type was added to
kairos-tx
:It represents full transaction data, including public key, hash (constructed from payload), algorithm (used for signing), and signature.
Notably,
kairos_tx::asn::Transaction
- similarly to payload - can be deterministically serialized and deserialized from bytes.Signer integration
Interacting with full transaction is now included in the
kairos-crypto
package (undertx
feature flag, enabled by default). The following methods are available in a signer trait:CryptoSigner::sign_tx_payload(&self, payload: SigningPayload) -> Result<Transaction, CryptoError>
.CryptoSigner::verify_tx(&self, tx: Transaction) -> Result<(), CryptoError>
.Those are implemented for Casper signer, with full ed25519 and secp256k1 support.