Skip to content

add Address Lookup Table program and support for version 0 transactions#7

Open
jochemarends wants to merge 4 commits intodcrck:masterfrom
jochemarends:master
Open

add Address Lookup Table program and support for version 0 transactions#7
jochemarends wants to merge 4 commits intodcrck:masterfrom
jochemarends:master

Conversation

@jochemarends
Copy link
Contributor

Hello,

Since transactions can now use address lookup tables, this commit adds support for the version 0 transaction format. This format is implicitly used when the :lookup_tables option is non-empty.

  • :lookup_tables (default: %{}) — A map of address lookup tables to use. Each key is a t:Solana.Key.t/0 representing the address of a lookup table account, and each value is a list of t:Solana.Key.t/0 representing the addresses of that lookup table.

    When non-empty, the transaction is encoded using the version 0 format.

Solana.Transaction.to_binary/2 now accepts two options; however, there's currently no way to use these with Solana.RPC.Request.send_transaction/2.
It might be nice to allow Solana.RPC.Request.send_transaction/2 to either accept pre-compiled transactions or forward these options to Solana.Transaction.to_binary/2.

Version 0 transaction cannot be parsed without an RPC connection.
Because Solana.Transaction.parse/1 currently does not have access to an RPC client, I have left it out the parsing of version 0 transactions for now.

I also left out the test for Solana.LookupTable.close_lookup_table/1 because closing a lookup table requires a cool-down period after deactivation, which caused the tests to time out.

Once there is way to send transactions that are compiled with options, I will add tests for version 0 transactions.

…ns (dcrck#6)

Since transactions can now use address lookup tables, this commit adds
support for the version 0 transaction format. This format is implicitly
used when the `:lookup_tables` option is non-empty:

- `:lookup_tables` (default: `%{}`) — A map of address lookup tables to use.
  Each key is a `t:Solana.Key.t/0` representing the address of a lookup table
  account, and each value is a list of `t:Solana.Key.t/0` representing the
  addresses of that lookup table.

  When non-empty, the transaction is encoded using the [version 0
  format](https://docs.anza.xyz/proposals/versioned-transactions#versioned-transactions).
Copy link
Owner

@dcrck dcrck left a comment

Choose a reason for hiding this comment

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

Hello,

Thank you so much for the pull request, and I apologize for taking so long to get around to reviewing it. I've been in a new job and these past few months have been very busy.

I've left some detailed feedback and stylistic change requests. Now that I've taken the time to read over the code I should be able to respond to comments on this one quickly. Please let me know if you have any questions or anything is confusing, and I'll get back to you ASAP.

Thanks again!

end
end

describe "extend_lookup_table/1" do
Copy link
Owner

Choose a reason for hiding this comment

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

the web3.js suite includes a a test for extending a lookup table without a payer, and that's an optional parameter for the function, so we should test that case here as well.

assert LookupTable.from_account_info(info).authority == nil
end
end

Copy link
Owner

Choose a reason for hiding this comment

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

missing close_lookup_table/1 test case

authority: pubkey!(new),
payer: pubkey!(payer),
new_keys: [SystemProgram.id()]
),
Copy link
Owner

Choose a reason for hiding this comment

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

Maybe extend the lookup table without a payer here to mimic the web3.js test suite?

@jochemarends
Copy link
Contributor Author

Hi,

Thank you for reviewing the pull request! I totally get that you're busy with other things, so please feel free to respond whenever it's convenient for you.

I appreciate the detailed feedback and already incorporated some of it. I will update the pull request once I found time to incorporate the rest.

- Change the default value for the `:bind_address` option of
  `Solana.TestValidator` to match the `--bind-address` option of
  `solana-test-validator` version 3.1.8.
- Remove the `:gossip_host` option for `Solana.TestValidator` as it's
  not supported in version 3.1.8 of `solana-test-validator`.
  `--bind-address` now controls the Gossip port.
- Add `:authority_should_sign?` option for `LookupTable.create_lookup_table/1`
- Add test for `LookupTable.close_lookup_table/1`.
- In the test for `LookupTable.deactivate_lookup_table/1` extend the lookup
  table without a payer to mimic the web3.js test suite.
@jochemarends
Copy link
Contributor Author

I've incorporated the feedback and ran the tests, which all passed. Since a certain amount of slots must elapse between the deactivation and the closing of a lookup table, the tests take about 3-4 minutes to execute.

Before merging, I would like to add test cases for Transaction.encode/2 to ensure lookup tables get encoded correctly, but I am not sure how to go about this, since parsing lookup tables requires a JSON-RPC client. Adding an additional parameter for this to Transaction.parse/1 is an option, but this would force a dependency on Solona.RPC even when parsing legacy transactions.

Here's a screenshots of the tests passing:

image

Also, I've had to make some changes to Solana.TestValidator, because --bind-address currently has a different default value, and --gossip-port is removed; its functionality is now covered by --bind-address.

Here's what solana-test-validator --help (version 3.1.8) says about --bind-address:

--bind-address <HOST>
    IP address to bind the validator ports. Can be repeated. The first --bind-address MUST be your public
    internet address. ALL protocols (gossip, repair, IP echo, TVU, TPU, etc.) bind to this address on startup.
    Additional --bind-address values enable multihoming for Gossip/TVU/TPU - these protocols bind to ALL
    interfaces on startup. Gossip reads/sends from one interface at a time. TVU/TPU read from ALL interfaces
    simultaneously but send from only one interface at a time. When switching interfaces via AdminRPC: Gossip
    switches to send/receive from the new interface, while TVU/TPU continue receiving from ALL interfaces but
    send from the new interface only. [default: 127.0.0.1]

# must be stored in the message itself
{static_accounts, lookup_accounts} =
accounts
|> Enum.split_with(&(&1.key not in keys or &1.signer? or &1 in invoked_accounts))
Copy link
Owner

Choose a reason for hiding this comment

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

Unless I'm missing some core library update,, in doesn't work for MapSet. You need to use MapSet.member?(invoked_accounts, &1) here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've tested it and it does work, but I can change it to MapSet.member? if that is preferred.

iex(1)> :foo in MapSet.new([:foo, :bar])
true

Copy link
Owner

Choose a reason for hiding this comment

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

I suppose in is OK, then :)

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.

2 participants