-
Notifications
You must be signed in to change notification settings - Fork 2.3k
[spl-record] Remove borsh dependency from spl-record program #6054
[spl-record] Remove borsh dependency from spl-record program #6054
Conversation
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.
Everything looks great! No show-stopping concerns, just some suggestions to make this better in subsequent work, if you'd like
Self::Write { offset, data } => { | ||
buf.push(1); | ||
buf.extend_from_slice(&offset.to_le_bytes()); | ||
buf.extend_from_slice(data); |
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.
Since the bytes are just written directly, this doesn't adhere to the borsh encoding scheme, which prefaces a variable-length type with its size as a u32
. I think it should be fine (and it gives us 4 extra bytes!), but it might confuse some people.
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.
Yes, good point. I added the vector length in the serialization.
/// The length of the data contained in the account for testing. | ||
const DATA_SIZE: usize = 8; |
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'm realizing I didn't do this amazingly 😓 to give yourself more flexibility, it might be easier to remove the whole Data
type and field, and just write arbitrary bytes into the provided account. But that can be done separately
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.
Okay, I think I can probably do this in a follow-up PR.
record/program/src/instruction.rs
Outdated
}; | ||
|
||
/// Instructions supported by the program | ||
#[derive(Clone, Debug, BorshSerialize, BorshDeserialize, PartialEq)] | ||
#[derive(Clone, Debug, PartialEq)] | ||
pub enum RecordInstruction { |
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 can't comment further down, but you could avoid some copies by having the Write
instruction and its creator take a byte slice. Doesn't need to be done here though
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.
Yes, this is a good idea. Updated!
Pull request has been modified.
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.
Looks great!
Problem
Currently, the zero-knowledge proofs that are required for the token-2022 program barely fits in a single transaction. The spl-record program provides a convenient way to break up the proofs into byte chunks to be submitted on chain. However, the record program depends on borsh serialization, which creates issues when combined with the zk-token-proof program.
Summary of changes
Remove the borsh dependency from the record program and use bytemuck for the serialization of data.