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

Migrate from address maps to address lookup tables #21634

Merged
merged 4 commits into from
Dec 10, 2021

Conversation

jstarry
Copy link
Member

@jstarry jstarry commented Dec 6, 2021

Problem

The transaction v2 proposal has new proposed changes that rename "address maps" to "address lookup tables" and the design of address lookup tables has shifted.

Summary of Changes

  • Rename "address map indexes" to "address table lookups" and "mapped addresses" to "loaded addresses"
  • Address map account keys used to be appended to message.account_keys but address table lookups track the account key separately.

Fixes #

@jstarry jstarry added the v1.9 label Dec 6, 2021
@jstarry jstarry force-pushed the migrate-address-maps branch from 04e54e3 to 5c96e59 Compare December 8, 2021 04:00
@jstarry jstarry marked this pull request as ready for review December 8, 2021 04:02
@jstarry
Copy link
Member Author

jstarry commented Dec 8, 2021

@lijunwangs can you please advise at what the impact of changing these Postgres types and tables will be?

@jstarry jstarry requested a review from lijunwangs December 8, 2021 04:03
@jstarry jstarry force-pushed the migrate-address-maps branch from 5c96e59 to 4e6c9d2 Compare December 8, 2021 04:04

// there should be at least 1 RW fee-payer account.
if self.header.num_readonly_signed_accounts >= self.header.num_required_signatures {
return Err(SanitizeError::IndexOutOfBounds);
Copy link
Contributor

Choose a reason for hiding this comment

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

I think probably SanitizeError::InvalidValue is more appropriate.

let num_table_loaded_accounts = lookup
.writable_indexes
.len()
.saturating_add(lookup.readonly_indexes.len());
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need validations for writable_indexes?

Copy link
Member Author

Choose a reason for hiding this comment

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

The writable and readonly indexes are used to lookup addresses in an on-chain address table. We can't sanitize those here, the runtime will fail in another location if the lookup fails. The indexes can be as high as u8::MAX so there's no need to sanitize them

}
}

Ok(())
Copy link
Contributor

Choose a reason for hiding this comment

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

Most of the errors returned in this function is IndexOutOfBounds, when one does run into such error -- it is actually difficult to figure out what causes it to fail. I guess some debug logging before the return will help.

Copy link
Member Author

Choose a reason for hiding this comment

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

This sanitization is done on the validator to filter out invalid transactions. It's not a method that users will interface with

Copy link
Contributor

Choose a reason for hiding this comment

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

Heh, I meant for the developer doing test. I found myself adding println! code in the error conditions to figure out what offended the sanitizer. I know this is not new code -- just copied from earlier location. And can be addressed separately.

#[serde(rename_all = "camelCase")]
pub struct MessageAddressTableLookup {
/// Address lookup table account key
pub account_key: Pubkey,
Copy link
Contributor

Choose a reason for hiding this comment

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

How is the account_key used? Where do we actually store the table?

Copy link
Member Author

Choose a reason for hiding this comment

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

There are many such tables (users can create their own as they please) and they are all on-chain accounts so they are identified by this account key.

Copy link
Contributor

Choose a reason for hiding this comment

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

Got it! Thanks

CREATE TYPE "AddressMapIndexes" AS (
writable SMALLINT[],
readonly SMALLINT[]
CREATE TYPE "TransactionMessageAddressTableLookup" AS (
Copy link
Contributor

Choose a reason for hiding this comment

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

Is the TransactionMessageAddressTable a global construct or stored in the transaction itself? If it is the former, we will have to persist that global table as well otherwise the indexes cannot be used.

Copy link
Member Author

Choose a reason for hiding this comment

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

Is the TransactionMessageAddressTable a global construct

It's stored on-chain so the full address table won't be included in the transaction object, but those addresses are resolved into "LoadedAddresses"

Copy link
Contributor

Choose a reason for hiding this comment

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

Cool. It should work then

@jstarry
Copy link
Member Author

jstarry commented Dec 9, 2021

@lijunwangs can you please advise at what the impact of changing these Postgres types and tables will be?

lijunwangs
lijunwangs previously approved these changes Dec 9, 2021
}
}

Ok(())
Copy link
Contributor

Choose a reason for hiding this comment

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

Heh, I meant for the developer doing test. I found myself adding println! code in the error conditions to figure out what offended the sanitizer. I know this is not new code -- just copied from earlier location. And can be addressed separately.

#[serde(rename_all = "camelCase")]
pub struct MessageAddressTableLookup {
/// Address lookup table account key
pub account_key: Pubkey,
Copy link
Contributor

Choose a reason for hiding this comment

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

Got it! Thanks

CREATE TYPE "AddressMapIndexes" AS (
writable SMALLINT[],
readonly SMALLINT[]
CREATE TYPE "TransactionMessageAddressTableLookup" AS (
Copy link
Contributor

Choose a reason for hiding this comment

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

Cool. It should work then

@mergify mergify bot dismissed lijunwangs’s stale review December 9, 2021 18:48

Pull request has been modified.

@@ -28,7 +28,7 @@ pub const MESSAGE_VERSION_PREFIX: u8 = 0x80;
/// which message version is serialized starting from version `0`. If the first
/// is bit is not set, all bytes are used to encode the legacy `Message`
/// format.
#[frozen_abi(digest = "x2F3RG2RhJQWN6L2N3jebvcAvNYFrhE3sKTPJ4sENvL")]
#[frozen_abi(digest = "G4EAiqmGgBprgf5ePYemLJcoFfx4R7rhC1Weo2FVJ7fn")]
Copy link
Contributor

Choose a reason for hiding this comment

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

Just out of curiosity, how is the new digest generated?

Copy link
Member Author

Choose a reason for hiding this comment

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

It's generated using some procedural macros that build a type graph and hash the output. I just ran ./test-abi.sh locally to see what the mismatch was and updated the value.

@codecov
Copy link

codecov bot commented Dec 9, 2021

Codecov Report

Merging #21634 (dec2065) into master (0224a8b) will decrease coverage by 0.0%.
The diff coverage is 89.0%.

@@            Coverage Diff            @@
##           master   #21634     +/-   ##
=========================================
- Coverage    81.6%    81.6%   -0.1%     
=========================================
  Files         511      511             
  Lines      143320   143304     -16     
=========================================
- Hits       116976   116962     -14     
+ Misses      26344    26342      -2     

@jstarry jstarry merged commit 6c108c8 into solana-labs:master Dec 10, 2021
@jstarry jstarry deleted the migrate-address-maps branch December 10, 2021 16:04
mergify bot pushed a commit that referenced this pull request Dec 10, 2021
* Migrate from address maps to address lookup tables

* update sanitize error

* cargo fmt

* update abi

(cherry picked from commit 6c108c8)
mergify bot added a commit that referenced this pull request Dec 10, 2021
* Migrate from address maps to address lookup tables

* update sanitize error

* cargo fmt

* update abi

(cherry picked from commit 6c108c8)

Co-authored-by: Justin Starry <justin@solana.com>
@brooksprumo brooksprumo mentioned this pull request Jan 5, 2022
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