barryWhiteHat
commented
5 years ago IIRC In the hackathon we represented the public keys for the rollup chain as two integers.
Yes, public keys are two field elements. which is similar to integerts but they have to be less than p. Where p ~= 2*253 - small_number*. Where the feild elements are an x and y coor on a eliptic curve.
I was wondering if we could reduce the pubkey to a single value for the purposes of the smart contract and clients, simply for convenience and clarity.
I think that the most we can do is replace it with 1 field element and a single bit. The reason being that for each x coord we have two posisbly y coords and the sign bit limits us to only one point.
serve as an account id
I was thinking of using the index in the merkle tree as the public key. But i now think its best to use the pubilc key and allow depositing into any leaf that has that public key in the leaf. That means you don't have to wait for your leaf to exist in order to send a transaction and the operator can make an account for you in that otken and then transfer it to you.
@GuthL However, at the hackathon we were talking about not being able to re-use the same public key for multiple deposits, which would preclude using it as an accountId.
Why not? Were you thinking i cant have the same public key in multiple leaves because all my transactions can be broadcast? If so we can have our signautes reference the from as teh index in the tree and the to as the public key.
Hey all, I wanted to clarify my understanding of keys in the rollup chain.
PubKey Format
IIRC In the hackathon we represented the public keys for the rollup chain as two integers.
I was wondering if we could reduce the pubkey to a single value for the purposes of the smart contract and clients, simply for convenience and clarity.
PubKey Functions
I'm currently thinking of the pubkeys in terms of a blockchain, where they function similarly to an Ethereum address.
So it would
As well as the usual functions
@GuthL However, at the hackathon we were talking about not being able to re-use the same public key for multiple deposits, which would preclude using it as an accountId.
Also, if this is the case it'll complicate key management on the client but I'm assuming we can use a mnemonic to generate an effectively infinite series of keys.