Support generic challenge signing. Introduce ABI deserialization.#361
Support generic challenge signing. Introduce ABI deserialization.#361
Conversation
0xmaayan
changed the title
0xmaayan
force-pushed
the
proof_challenege
branch
2 times, most recently
from
9835f19 to
6be06b2
Compare
0xmaayan
changed the title
0xmaayan
force-pushed
the
proof_challenege
branch
2 times, most recently
from
ce814c6 to
273ce91
Compare
BriungRi
left a comment
BriungRi
left a comment
There was a problem hiding this comment.
Could the DevX be simpler here if createProofChallenge took two Account instead?
const account1 = new Account();
const account2 = new Account()
const proofChallenge = createProofChallenge({currentAccount: account1, newAccount: account2})
Seems like having to pass in all these different keys could be mistake-prone.
| }); | ||
|
|
||
| const challenge = await aptos.createProofChallenge({ | ||
| struct: "0x1::account::RotationProofChallenge", |
There was a problem hiding this comment.
are there other structs that are valid here?
There was a problem hiding this comment.
wdym? it is a generic implementation so any struct serves as a proof challenge is valid here
tests/e2e/api/proofChallenge.test.ts
Outdated
|
|
||
| const response = await aptos.signAndSubmitTransaction({ signer: fromAccount, transaction }); | ||
| const executedTransaction = await aptos.waitForTransaction({ transactionHash: response.hash }); | ||
| expect(executedTransaction.success).toBeTruthy(); |
There was a problem hiding this comment.
should we check if the on-chain public key has also changed?
It is very specific - not sure all proof challenges require 2 signatures. Also, it can be tricky from a wallet perspective when there is only one signer/wallet |
0xmaayan
force-pushed
the
proof_challenege
branch
3 times, most recently
from
e1d32ca to
8d0fe99
Compare
0xmaayan
changed the title
3 participants
Description
Following a community and a foundation request, adding support for generic challenge signing.
With the new generic challenge signing support this PR also introduces deserialization process with the types coming from a remote abi.
There are some limitation to the deserialization process
vector<u8>can be a serialization representative to some types such as: public keys (ed25519, secp256k1, etc), string, etc. Since we can't really know anything about the value type other than it is avector of u8, deserializing it is a bit challenging. Therefore, the sdk would try to deserialize it as a ed25519 public key type and if it fails it would return the array of u8 itself.GenericorOptiontypes are not supported by the SDK as thedeserializerclass in the SDK can only handle a single class, i.e not a class with generics.Future work
To not overload this work, will follow with next PRs to
remoteAbi.tsfile needs to be refactoredTest Plan
added a new test for generic challenge
added tests for abi deserialization
tests are passing
Related Links