Add verification feature #631

kairoski03 · 2023-11-15T10:18:02Z

Hello,
I added code verification feature.
The feature enables user to check if the source code matches to the on-chain bytecode.
User can choose verification service by changing url input.
The verification server get source code by account resource query and builds the source code
and compares the built bytecode to on-chain bytecode.
Please refer to below screenshots.

gregnazario

Generally, it looks alright. I have a few requests though:

Would like to see how it's being verified / a link to the source code for it. Error messages are a little cloudy / it's failing to compile on the framework, which is strange.
Minor: Verification service should be a little smarter. No reason to compile if it's already been compiled and not changed (this might require more work). This is purely an optimization though, and could still always compile on each button click.
Please fix the lints so the build succeeds, as shown in the CI below

src/pages/Account/Components/codeDescription.ts

src/pages/Account/Components/VerificationButton.tsx

gregnazario · 2024-01-09T19:14:37Z

src/pages/Account/Components/VerificationButton.tsx

+        setIsInProgress(false);
+        if (dto.errMsg) {
+          setVerificationStatus("NOT_VERIFIED");
+          setVerificationServerErr(`${dto.errMsg}`);


My main concern is the messages that currently come out of this need to be cleaned up a bit. Would be great to see some of the code for the verification service.

I fixed verification server to show the actual error message.
(ex. Move compilation failed: Unable to resolve packages for package 'AptosFramework': While resolving dependency 'AptosStdlib' in package 'AptosFramework': While processing dependency 'AptosStdlib': Unable to find package manifest for 'AptosStdlib' at "~/mainnet/0x1/1704956814227/../aptos-stdlib" )

src/pages/Account/Components/CodeSnippet.tsx

gregnazario · 2024-01-09T19:17:16Z

src/constants.tsx

+export const defaultVerificationServiceUrl =
+  "https://verify.welldonestudio.io/aptos";
+


If there's a service for this, we should possibly provide help details somewhere for how someone can run it themselves. Since, this is essentially trusting this URL entirely, it would be good to provide a more trustless system (you can run it yourself), or that the foundation will run it.

I will inform you once I have prepared for it.

…-labs#631)

kairoski03 · 2024-01-11T07:03:22Z

Hello, @gregnazario.

Thank you for your feedback.

I answered your questions below.

Would like to see how it's being verified / a link to the source code for it. Error messages are a little cloudy / it's failing to compile on the framework, which is strange.
→ I tried to add your github account to the verification server source code repository, but i had a some trouble. I will let you know after adding you.
Minor: Verification service should be a little smarter. No reason to compile if it's already been compiled and not changed (this might require more work). This is purely an optimization though, and could still always compile on each button click.
→ I agree with you. I will optimize it after solving other things.
Please fix the lints so the build succeeds, as shown in the CI below
→ Fixed.

I updated the version of Aptos CLI to the latest 2.4.0 which the verification server uses to compile.

Current verification service has two limitations.

In Move.toml from on-chain, dependencies should be defined by git.
Because verification server can't get dependencies defined by local, compile errors occur.

- AptosStdlib = { local = "../aptos-stdlib" }
→ It’s not available. ( dependency defined by local path in upper directory )
- AptosStdlib = { local = "./aptos-stdlib" }
→ It’s not available. ( dependency defined by local path in current directory )
- AptosStdlib = { git = "https://github.com/aptos-labs/aptos-core.git", subdir = "aptos-move/framework/aptos-stdlib/", rev = "main" }
→ It’s available.

When a move file has a reference to spec, verification is not available.
For example, coin.move in aptos-framework has a part which refers to coin.spec.move.
Because the coin.spec.move is not uploaded when publishing, the verification server can’t download coin.spec.move and compile errors occur.

I am considering below solutions for this limitation.

Add a file upload UI so that the package publisher or someone can upload full source code.
If a user publish using remix wellondone studio plugin ( web ide ), the source files are uploaded on the cloud. I will use the source code when verifying the source code.

It would be appreciate if you have a comment about this limitations.

gregnazario · 2024-01-11T20:24:36Z

Hello, @gregnazario.

Thank you for your feedback.

I answered your questions below.

Would like to see how it's being verified / a link to the source code for it. Error messages are a little cloudy / it's failing to compile on the framework, which is strange.
→ I tried to add your github account to the verification server source code repository, but i had a some trouble. I will let you know after adding you.

Minor: Verification service should be a little smarter. No reason to compile if it's already been compiled and not changed (this might require more work). This is purely an optimization though, and could still always compile on each button click.
→ I agree with you. I will optimize it after solving other things.

Please fix the lints so the build succeeds, as shown in the CI below
→ Fixed.

I updated the version of Aptos CLI to the latest 2.4.0 which the verification server uses to compile.

Current verification service has two limitations.

In Move.toml from on-chain, dependencies should be defined by git.
Because verification server can't get dependencies defined by local, compile errors occur.

- AptosStdlib = { local = "../aptos-stdlib" }
→ It’s not available. ( dependency defined by local path in upper directory )

- AptosStdlib = { local = "./aptos-stdlib" }
→ It’s not available. ( dependency defined by local path in current directory )

- AptosStdlib = { git = "https://github.com/aptos-labs/aptos-core.git", subdir = "aptos-move/framework/aptos-stdlib/", rev = "main" }
→ It’s available.

When a move file has a reference to spec, verification is not available.
For example, coin.move in aptos-framework has a part which refers to coin.spec.move.
Because the coin.spec.move is not uploaded when publishing, the verification server can’t download coin.spec.move and compile errors occur.

I am considering below solutions for this limitation.

Add a file upload UI so that the package publisher or someone can upload full source code.

If a user publish using remix wellondone studio plugin ( web ide ), the source files are uploaded on the cloud. I will use the source code when verifying the source code.

It would be appreciate if you have a comment about this limitations.

Yeah, I'm aware of those limitations, which can be a pain.

For now, maybe when we know it's address 0x1, that we can use the dependencies direct from git just so it doesn't say "it's unverified", especially since. The source code is uploaded at the same time

gregnazario

The service doesn't seem to handle named addresses correctly. If there's a named address, it just fails.

kairoski03 · 2024-01-15T09:27:06Z

The service doesn't seem to handle named addresses correctly. If there's a named address, it just fails.

I heard that you inquired with sooyoung as follows.
How do we handle named addresses in verification?

and I received a below link for test.
https://explorer.aptoslabs.com/account/0x3b36cac0ec1054b6a99facdef2a0015a2858ff75d10251590e606365394ac5bd/modules/code/tic_tac_toe?network=mainnet

I could not compile the source code from on-chain even though I filled named address with CLI 2.4.0.
I had to change CLI version to 1.0.7 and AptosFramework rev from main to eafa8d2.

CLI Version	Github Rev	Compile Result	Bytecode Comparison
1.0.7	eafa8d2	Success	Matches
1.0.7	main (d20fab97)	Fail	-
2.4.0	eafa8d2	Fail	-
2.4.0	main (d20fab97)	Success	Doesn’t Match

I seems that additional version information needs to be uploaded to onchain when publishing packages to verify stable.

For now, the service does not handle named addresses.

To test,

added additional named address. ( @address_a, @address_b, @address_c )
added initialize function
changed winner func name to a_winner

and compiled and analyzed bytecode.

a11ceb0b // magic word
06000000 // file format version
0c // table count
01000c ...omit...

// ------------- module name -------------
0b 7469635f7461635f746f65 // tic_tac_toe
06 7369676e6572 0a 73696d706c655f6d6170 ... omit ...
// ---------------------------------------

// ------------------- func -------------------
08 615f77696e6e6572                 // a_winner
0e 63757272656e745f706c61796572     // current_player
0b 64656c6574655f67616d65           // delete_game
0c 64656c6574655f73746f7265         // delete_store
09 6765745f626f617264               // get_board
0a 696e697469616c697a65             // initialize
0a 706c61795f7370616365             // play_space
07 706c6179657273                   // public fun players
0a 72657365745f67616d65             // reset_game
0a 73746172745f67616d65             // start_game
// --------------------------------------------

// ------------- member of struct, external struct ... -------------
05 626f617264 // board
08 785f706c61796572 // x_player
... omit ...
// -----------------------------------------------------------------

// ---------------------------- const ----------------------------
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff // package address
0000000000000000000000000000000000000000000000000000000000000001 // std, aptos_framework, aptos_std address
0201 03               // const DRAW: u8 = 3;
0308 0900000000000000 // const EGAME_ALREADY_EXISTS: u64 = 9;
0308 0800000000000000 // const EGAME_NOT_FOUND: u64 = 8;
0308 0100000000000000 // const EGAME_NOT_OVER: u64 = 1;
0308 0600000000000000 // const EGAME_OVER: u64 = 6;
0308 0e00000000000000 // const EINVALID_ADDRESS: u64 = 14;
0308 0300000000000000 // const EINVALID_PLAYER: u64 = 3;
0308 0a00000000000000 // const EINVALID_RESETTER: u64 = 10;
0308 0500000000000000 // const ENOT_O_PLAYER_TURN: u64 = 5;
0308 0400000000000000 // const ENOT_X_PLAYER_TURN: u64 = 4;
0308 0c00000000000000 // const EOUT_OF_BOUNDS: u64 = 12;
0308 0200000000000000 // const EPLAYER_NOT_WINNER: u64 = 2;
0308 0b00000000000000 // const EINVALID_PLAYER: u64 = 3;
0308 0700000000000000 // const ESPACE_ALREADY_PLAYED: u64 = 7;
0308 0d00000000000000 // const ESTORE_NOT_FOUND: u64 = 13;
0201 00               // const NONE: u8 = 0;
0201 02               // const O: u8 = 2;
0201 01               // const X: u8 = 1;
0520 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb // named address @address_b in func a_winner
0520 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa // named address @address_a in func current_player
0520 cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc // named address @address_c in func initialize
// -----------------------------------------------------------------

12617074 ...omit...

I have some questions.

Could you provide some document about the bytecode structure?
I don't understand exactly the structure of bytecode.
Does the order in which addresses are displayed within the bytecode match the alphabetical order of function names?
Is it possible to know the start offset and end offset of func part?
Is it possible to know the start offset and end offset of named address part?

I am considering trying the following method.

Extract the actual address of named address from bytecode.
Extract pairs of func and named addresses from onchain module source code.
Sort the func and named addresses pair by alphabetical func name and map the named address to actual address.
Replace underbar in named address of actual address in Move.toml.

I would appreciate your opinion on whether above method is a feasible approach.

kairoski03 · 2024-01-15T09:40:52Z

I added @gregnazario to the repository of the verification server.

Below is the part of verification logic.

https://github.com/dsrvlabs/wds-compiler/blob/26c0310dc9f537a72aac4eb455f81e453b0bc713/src/domain/verification/aptos/aptos-verification.service.ts#L93

kairoski03 · 2024-05-09T01:39:19Z

@gregnazario Hello, Greg.

I granted a github repo read permission of verification server as you requested.
( https://github.com/dsrvlabs/wds-compiler.git )

But it seems that the progress is pending for a long time.
So I'm about to revoke your GitHub permission for now.

When you can initiate the review again, please let me know, and I'll grant the permission again.

kairoski03 and others added 2 commits November 15, 2023 18:54

Add verification feature

65e2401

Merge branch 'main' into verification

e395ddc

gregnazario requested review from kent-white and movekevin January 9, 2024 18:47

gregnazario reviewed Jan 9, 2024

View reviewed changes

kairoski03 and others added 2 commits January 11, 2024 15:38

Merge branch 'aptos-labs:main' into verification

d1ab871

refactor verification related status, text, style and fix lint (aptos…

da95892

…-labs#631)

kairoski03 added a commit to welldonestudio/explorer-aptos that referenced this pull request Jan 11, 2024

GitHub action for deployment (aptos-labs#631)

00a0561

kairoski03 added a commit to welldonestudio/explorer-aptos that referenced this pull request Jan 11, 2024

fix GitHub action (aptos-labs#631)

b827a8d

kairoski03 added a commit to welldonestudio/explorer-aptos that referenced this pull request Jan 11, 2024

fix GitHub action (aptos-labs#631)

c358567

kairoski03 added a commit to welldonestudio/explorer-aptos that referenced this pull request Jan 11, 2024

fix GitHub action (aptos-labs#631)

4158637

kairoski03 requested a review from gregnazario January 11, 2024 09:25

gregnazario reviewed Jan 12, 2024

View reviewed changes

kairoski03 requested a review from gregnazario January 23, 2024 06:13

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add verification feature #631

Add verification feature #631

kairoski03 commented Nov 15, 2023

gregnazario left a comment •

edited

Loading

gregnazario Jan 9, 2024

kairoski03 Jan 11, 2024

gregnazario Jan 9, 2024

kairoski03 Jan 11, 2024

kairoski03 commented Jan 11, 2024 •

edited

Loading

gregnazario commented Jan 11, 2024

gregnazario left a comment

kairoski03 commented Jan 15, 2024 •

edited

Loading

kairoski03 commented Jan 15, 2024

kairoski03 commented May 9, 2024

		export const defaultVerificationServiceUrl =
		"https://verify.welldonestudio.io/aptos";

Add verification feature #631

Are you sure you want to change the base?

Add verification feature #631

Conversation

kairoski03 commented Nov 15, 2023

gregnazario left a comment • edited Loading

Choose a reason for hiding this comment

gregnazario Jan 9, 2024

Choose a reason for hiding this comment

kairoski03 Jan 11, 2024

Choose a reason for hiding this comment

gregnazario Jan 9, 2024

Choose a reason for hiding this comment

kairoski03 Jan 11, 2024

Choose a reason for hiding this comment

kairoski03 commented Jan 11, 2024 • edited Loading

gregnazario commented Jan 11, 2024

gregnazario left a comment

Choose a reason for hiding this comment

kairoski03 commented Jan 15, 2024 • edited Loading

kairoski03 commented Jan 15, 2024

kairoski03 commented May 9, 2024

gregnazario left a comment •

edited

Loading

kairoski03 commented Jan 11, 2024 •

edited

Loading

kairoski03 commented Jan 15, 2024 •

edited

Loading