Skip to content
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

Verification refcounted key hash table in transaction pool #12398

Merged
merged 30 commits into from
Jan 21, 2023

Conversation

bkase
Copy link
Member

@bkase bkase commented Dec 19, 2022

Adds a verification key refcounted table in the transaction pool to track keys as they enter/exit the mempool.

Also adjusted the User_command.to_verifiable to be more flexible with its fallback rather than assume it's a ledger lookup.

Plan to test this as part of #12364

Fixes XXX

@bkase bkase requested a review from a team as a code owner December 19, 2022 23:19
| None ->
None
| Some (x, value) ->
if Int.equal x 1 then None else Some (x - 1, value) )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can use x = 1

Copy link
Member

@deepthiskumar deepthiskumar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the ref counts need to be updated in this function as well.

let handle_transition_frontier_diff

zkapp.verification_key
with
| Some vk ->
Ok vk
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we check if the vk hash is as expected?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

(* we haven't set anything; lookup the vk in the fallback *)
let vk_hash =
failwith
"TODO: Lookup the vk_hash inside this account update"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

impl this? vk hash should be available in account updates

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops, thanks forgot about this

@@ -327,6 +327,29 @@ struct
t
end

module Vk_refcount_table = struct
(* what's the right incantation of "field" here that is better than State_hash but will compile *)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Zkapp_basic.F maybe?

@@ -1023,7 +1023,12 @@ module T = struct
Or_error.try_with (fun () ->
List.map cs ~f:(fun cmd ->
let open Ledger in
User_command.to_verifiable ~ledger ~get ~location_of_account cmd
(* TODO: what are we supposed to do here? *)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need to do anything here. Verifiable.create does what's required

@@ -1386,6 +1395,21 @@ end = struct
end
end]

let find_vk_via_ledger ~ledger ~get ~location_of_account _vk_hash account_id =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: make it a labelled arg ~expected_vk_hash?

@bkase
Copy link
Member Author

bkase commented Dec 21, 2022

I am very not confident that I covered the handle_transition_frontier_diff is properly instrumented with vk_refcount_table inc and dec (this is the scary part of using the ref counted table). Please review very carefully.

User_command.to_verifiable ~ledger ~get ~location_of_account cmd
User_command.to_verifiable
~find_vk:
(Zkapp_command.Verifiable.find_vk_via_ledger ~ledger ~get
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't this get the wrong vk if one zkApp command sets it and a later one attempts to use it? It feels like we need to accumulate across all of the commands.

zkapp.verification_key
with
| Some vk ->
Ok vk
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@@ -1655,7 +1666,8 @@ struct
let forget (t : t) : T.t = t.zkapp_command

let to_valid (t : T.t) ~ledger ~get ~location_of_account : t Or_error.t =
Verifiable.create t ~ledger ~get ~location_of_account
Verifiable.create t
~find_vk:(Verifiable.find_vk_via_ledger ~ledger ~get ~location_of_account)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to pass this in as an argument? Looking in the ledger is not always the right thing to do (although it's possible this is only used in tests..)

Ok z
in
(* first we check if there's anything in the running cache within this diff so far *)
F.Map.find running_cache vk_hash
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to factor out (some of) this logic into a function in Zkapp_command? It seems like we probably want something similar to this in (at least) the staged ledger diff application logic too.

include Comparable.Make (T)
end

let extract_vks : User_command.t -> Verification_key_wire.t List.t =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably shouldn't live here. In User_command / Zkapp_command / both?

@bkase
Copy link
Member Author

bkase commented Jan 6, 2023

!ci-build-me

@bkase
Copy link
Member Author

bkase commented Jan 13, 2023

!ci-build-me

Copy link
Member

@mrmr1993 mrmr1993 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but I suspect the zkapps_examples are broken due to the patch (and if they're not, we're not testing them properly / something is broken!)

User_command.Zkapp_command valid_zkapp_command
| Signed_command _ ->
failwith "Expected Zkapp_command valid user command" )
let sequence_or_error (xs : 'a Or_error.t list) : 'a list Or_error.t =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Or_error.combine_errors?

; caller = t.caller
; caller =
t.caller
(* the vk hash is a dummy, to be patched with `patch_verification_key_hashes`, below *)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: shift this comment down?

~ledger zkapp_command =
~ledger zkapp_command0 =
let zkapp_command =
Zkapps_examples.patch_verification_key_hashes ~ledger zkapp_command0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that it's valid to patch at this stage.. I think you need to pass the verification key hash into the circuit while it's constructing the transaction, in the same way we do for public_key, token_id, caller, etc.

Specifically, this test checked that staged ledger diffs filter out commands that
fail to check against the verification key given from the ledger. However, now that
verification key hashes are part of user commands, we check _in the prediff_ that the
verificaiton keys are valid.
@bkase
Copy link
Member Author

bkase commented Jan 19, 2023

!ci-build-me

@bkase bkase merged commit 3ddb7ac into feature/vk-hash-in-acct-updates Jan 21, 2023
@bkase bkase deleted the verification-key-hash-table branch January 21, 2023 09:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants