Performing multiple secp256k1 pubkey recovery operations (ecrecover) in BPF would exceed the transction bpf instruction limit and even if the limit is increased it would take a long time to process. ecrecover is an ethereum instruction which takes a signature and message and recovers a publickey, a comparison to that public key can thus verify that the signature is valid.
Since there needs to be 10-20 signatures in the transaction as well as the signing data which is on the order of 500 bytes, transaction space is a concern. But also having more concentrated similar work should provide for easier optimization.
Add a new builtin instruction which takes in as the first byte a count of the following struct serialized in the instruction data:
Pseudo code of the operation:
This allows the user to specify any instruction data in the transaction for signature and message data. By specifying a special instructions sysvar, one can also receive data from the transaction itself.
Cost of the transaction will count the number of signatures to verify multiplied by the signature cost verify multiplier.
The operation will have to take place after (at least partial) deserialization, but all inputs come from the transaction data itself, this allows it to be relatively easy to execute in parallel to transaction processing and PoH verification.
Instruction available as CPI such that the program can call as desired or a syscall which can operate on the instruction inline.
- Could be harder to optimize given that it generally either requires bpf program scan to determine the inputs to the operation, or the implementation needs to just wait until the program hits the operation in bpf processing to evaluate it.
- Vector version of the operation could allow for somewhat efficient simd/gpu execution. For most efficient though, batching with other instructions in the pipeline would be ideal.
- Pros - Nicer interface for the user.
Async execution environment inside bpf
- Might be hard to optimize for devices like gpus which cannot queue work for itself easily
- Might be easier to optimize on cpu since ordering can be more explicit
All inputs have to come from the instruction
- Pros - easier to optimize, data is already sent to the GPU for instance for regular sigverify. Probably still need to wait for deserialize though.
- Cons - ask for pubkeys outside the transaction data itself since they would not be stored on the transaction sending client, and larger transaction size.