diff --git a/docs/developing/deploy_facilities/configure_foundry.md b/docs/developing/deploy_facilities/configure_foundry.md index 08924c44..a6d5a196 100644 --- a/docs/developing/deploy_facilities/configure_foundry.md +++ b/docs/developing/deploy_facilities/configure_foundry.md @@ -1,5 +1,5 @@ --- -title: "Configure Foundry" +title: 'Configure Foundry' proofedDate: 20231116 iterationBy: na includedInSite: true @@ -14,11 +14,27 @@ Foundry is a blazing fast, portable,modular toolkit for Ethereum application dev This page details several parameters required to configure Foundry. The Foundry framework isn't described here; find that in the [Foundry documentation](https://book.getfoundry.sh). ## Prerequisites + - cURL ## Foundry configuration -Unlike other toolkits, Foundry doesn't have a config file to hold the chain parameters, instead, parameters are passed into commands. For example, this command deploys a smart contract: +Unlike other toolkits, Foundry doesn't have a config file to hold the chain parameters, instead, parameters are passed into commands. + +1. The following command deploys a contract using a script: + +``` +forge script script/TestERC20/DeployTestERC20.s.sol:DeployTestERC20Script --broadcast --rpc-url $RPC_URL_DEVNET --legacy --skip-simulation +``` + +The parameters for `forge script` command include: + +- `--rpc-url`: RPC URL +- `--skip-simulation`: This parameter skips the on-chain simulation which doesn't work on Neon EVM. +- `--broadcast`: This parameter broadcasts the transaction. +- `--legacy`: This parameter is being passed to use legacy transactions _(Neon EVM currently [doesn't support EIP-1559 transactions](/docs/evm_compatibility/overview#shared-standards-and-features))_ + +2. The following command deploys a contract directly without a script: ``` forge create --rpc-url $RPC_URL_DEVNET \ @@ -28,10 +44,10 @@ src/TestERC20/TestERC20.sol:TestERC20 ``` The parameters for `forge create` command include: -* `--rpc-url`: RPC URL -* `--private-key`: The private key of the transaction signer -* `--constructor-args`: The constructor arguments to be passed to the contract that is being deployed -* `--legacy`: This parameter is being passed to use legacy transactions _(Neon EVM currently [doesn't support EIP-1559 transactions](/docs/evm_compatibility/overview#shared-standards-and-features))_ +- `--rpc-url`: RPC URL +- `--private-key`: The private key of the transaction signer +- `--constructor-args`: The constructor arguments to be passed to the contract that is being deployed +- `--legacy`: This parameter is being passed to use legacy transactions _(Neon EVM currently [doesn't support EIP-1559 transactions](/docs/evm_compatibility/overview#shared-standards-and-features))_ -## What next? See the [tutorial on how to use Foundry](/docs/developing/deploy_facilities/using_foundry) to deploy to Neon EVM. +### What next? See the [tutorial on how to use Foundry](/docs/developing/deploy_facilities/using_foundry) to deploy on Neon EVM. diff --git a/docs/developing/deploy_facilities/using_foundry.md b/docs/developing/deploy_facilities/using_foundry.md index 739cd052..b9f02b11 100644 --- a/docs/developing/deploy_facilities/using_foundry.md +++ b/docs/developing/deploy_facilities/using_foundry.md @@ -209,6 +209,8 @@ Total Paid: 0.0034876870402 ETH (20000 gas * avg 174.38435201 gwei) ``` :::important +`--skip-simulation` parameter skips the on-chain simulation which doesn't work on Neon EVM. + The native token displayed above should be NEON instead of ETH and the unit should be Galan instead of gwei (It is not possible to customize the display). ::: diff --git a/docs/developing/get-started.md b/docs/developing/get-started.md index 8c3fd937..f93b6228 100644 --- a/docs/developing/get-started.md +++ b/docs/developing/get-started.md @@ -60,7 +60,7 @@ neonmainnet: { -See the [Hardhat tutorial](https://docs.neonfoundation.io/docs/developing/deploy_facilities/configure_hardhat) +See the [Hardhat tutorial](/docs/developing/deploy_facilities/configure_hardhat) diff --git a/docs/developing/integrate/indexer/subsquid.md b/docs/developing/integrate/indexer/subsquid.md new file mode 100644 index 00000000..7809be63 --- /dev/null +++ b/docs/developing/integrate/indexer/subsquid.md @@ -0,0 +1,220 @@ +--- +title: 'Subsquid SDK Integration' +proofedDate: N/A +includedInSite: false +approvedBy: na +description: Serves historical on-chain data, including event logs, transaction receipts, traces and per-transaction state diffs. +--- + +_This page presents an example of how SDK packages can be combined into a working indexer (called squid) on Neon EVM Devnet. This squid example tracks transfers of WNEON on Neon EVM Devnet, then save the resulting data to PostgreSQL and serve it as a GraphQL API._ + +# Introduction + +[Subsquid Network](https://docs.subsquid.io/) is a decentralized query engine optimized for batch extraction of large volumes of data. It currently serves historical on-chain data ingested from 100+ EVM and Substrate networks, including event logs, transaction receipts, traces and per-transaction state diffs. + +Here's an example of how SDK packages can be combined into a working indexer (called squid). This example uses [WNEON contract](https://devnet.neonscan.org/address/0x11adc2d986e334137b9ad0a0f290771f31e9517f). + +## Prerequisites + +- NodeJS 16.x or newer +- Docker + +## How to run a squid on Neon EVM Devnet + +### Step 1: Initialize a node project + +Create an empty project directory and navigate to it and run: + +```sh +npm init +``` + +### Step 2: Install dependencies + +```sh +npm i @subsquid/evm-processor @subsquid/typeorm-store @subsquid/typeorm-migration @subsquid/graphql-server + +npm i typescript @subsquid/typeorm-codegen @subsquid/evm-typegen @@subsquid/util-internal-validation --save-dev +``` + +### Step 3: Add `tsconfig.json` to the project's root directory + +```sh +{ + "compilerOptions": { + "rootDir": "src", + "outDir": "lib", + "module": "commonjs", + "target": "es2020", + "esModuleInterop": true, + "skipLibCheck": true, + "experimentalDecorators": true, + "emitDecoratorMetadata": true + } +} +``` + +### Step 4: Define the schema for both the database and the core GraphQL API in `schema.graphql` in the project's root directory + +```sh +type Transfer @entity { + id: ID! + src: String! @index + dst: String! @index + wad: BigInt! +} +``` + +### Step 5: Generate TypeORM classes based on the schema + +```sh +npx squid-typeorm-codegen +``` + +The TypeORM classes will be available at `src/model/index.ts`. + +### Step 6: Prepare the database + +6.1 Create `.env` file in the project's root directory and paste the following lines - + +```sh +DB_NAME=squid +DB_PORT=23798 +RPC_NEON_HTTP=https://devnet.neonevm.org +GQL_PORT=4350 +``` + +6.2 Create `docker-compose.yaml` file in the project's root directory and paste the following lines - + +```sh +version: "3" +services: + db: + image: postgres:15 + environment: + POSTGRES_DB: "${DB_NAME}" + POSTGRES_PASSWORD: postgres + ports: + - "${DB_PORT}:5432" +``` + +6.3 Start the database container - + +```sh +docker compose up -d +``` + +6.4 Compile the TypeORM classes - + +```sh +npx tsc +``` + +6.5 Generate the migration file - + +```sh +npx squid-typeorm-migration generate +``` + +6.6 Apply the migration with - + +```sh +npx squid-typeorm-migration apply +``` + +### Step 7: Generate utility classes for decoding WNEON contract data based on its ABI + +7.1 Create a folder named `abi` under `src` (`src/abi`). + +7.2 Create `wneon.json` file under `src/abi` (`src/abi/wneon.json`) and paste the contracts's ABI (https://devnet.neonscan.org/address/0x11adc2d986e334137b9ad0a0f290771f31e9517f#contract) into it. + +7.3 Run - + +```sh +npx squid-evm-typegen src/abi ./src/abi/wneon.json +``` + +The utility classes will be available at src/abi/wneon.ts. + +### Step 8: Create an executable file `main.ts` under `src` folder (`src/main.ts`) + +Paste the following lines of code into `main.ts` - + +```sh +import { EvmBatchProcessor } from "@subsquid/evm-processor"; +import { TypeormDatabase } from "@subsquid/typeorm-store"; +import * as wneonAbi from "./abi/wneon"; +import { Transfer } from "./model"; + +const processor = new EvmBatchProcessor() + .setGateway("https://v2.archive.subsquid.io/network/neon-devnet") + .setRpcEndpoint({ + // set RPC endpoint in .env + url: process.env.RPC_NEON_HTTP, + //rateLimit: 10, + }) + .setBlockRange({ from: 177455580 }) // Neon EVM Devnet genesis block + .setFinalityConfirmation(75) // 15 mins to finality + .addLog({ + address: ["0x11adC2d986E334137b9ad0a0F290771F31e9517F"], // WNEON contract address on Neon EVM Devnet + topic0: [wneonAbi.events.Transfer.topic], + }); + +const db = new TypeormDatabase(); + +processor.run(db, async (ctx) => { + const transfers: Transfer[] = []; + for (let block of ctx.blocks) { + for (let log of block.logs) { + let { src, dst, wad } = wneonAbi.events.Transfer.decode(log); + transfers.push( + new Transfer({ + id: log.id, + src, + dst, + wad, + }) + ); + } + } + await ctx.store.insert(transfers); +}); +``` + +### Step 9: Compile the project and start the processor process + +```sh +npx tsc +``` + +```sh +node -r dotenv/config lib/main.js +``` + +### Step 10: Start the GraphQL server + +In a separate terminal, run the graphql server - + +```sh +npx squid-graphql-server +``` + +The finished GraphQL API with GraphiQL will be available at localhost:4350/graphql. + +:::info +Please follow the quick start github tutorial _[Subsquid SDK Example](https://github.com/neonlabsorg/neon-tutorials/tree/main/subsquid)_. +::: + +## Changes needed to run a squid on Neon EVM Mainnet + +To run a squid on Neon EVM Mainnet, there needs to be some changes to some of the above mentioned steps. + +1. Replace `RPC_NEON_HTTP=https://devnet.neonevm.org` to `RPC_NEON_HTTP=https://neon-proxy-mainnet.solana.p2p.org` in the `.env` file in **Step 6.1** + +2. Get the WNEON contract's ABI from the mainnet (https://neonscan.org/address/0x202c35e517fa803b537565c40f0a6965d7204609#contract) in **Step 7.2** + +3. In **Step 8**, change to the following in the `src/main.ts` file: + +- `setGateway("https://v2.archive.subsquid.io/network/neon-mainnet")` +- `setBlockRange({ from: 195350522 })` (Neon EVM Mainnet genesis block) +- `address: ["0x202c35e517fa803b537565c40f0a6965d7204609"]` (WNEON contract address on Neon EVM Mainnet) diff --git a/docs/developing/verify_facilities/img/blockscout-1.png b/docs/developing/verify_facilities/img/blockscout-1.png new file mode 100644 index 00000000..0191d9e7 Binary files /dev/null and b/docs/developing/verify_facilities/img/blockscout-1.png differ diff --git a/docs/developing/verify_facilities/img/blockscout-2.png b/docs/developing/verify_facilities/img/blockscout-2.png new file mode 100644 index 00000000..2f6133cc Binary files /dev/null and b/docs/developing/verify_facilities/img/blockscout-2.png differ diff --git a/docs/developing/verify_facilities/img/blockscout-3.png b/docs/developing/verify_facilities/img/blockscout-3.png new file mode 100644 index 00000000..a20618ab Binary files /dev/null and b/docs/developing/verify_facilities/img/blockscout-3.png differ diff --git a/docs/developing/verify_facilities/img/blockscout-4.png b/docs/developing/verify_facilities/img/blockscout-4.png new file mode 100644 index 00000000..b7de47ea Binary files /dev/null and b/docs/developing/verify_facilities/img/blockscout-4.png differ diff --git a/docs/developing/verify_facilities/img/blockscout-5.png b/docs/developing/verify_facilities/img/blockscout-5.png new file mode 100644 index 00000000..6cd96d9a Binary files /dev/null and b/docs/developing/verify_facilities/img/blockscout-5.png differ diff --git a/docs/developing/verify_facilities/img/blockscout-6.png b/docs/developing/verify_facilities/img/blockscout-6.png new file mode 100644 index 00000000..477b0f89 Binary files /dev/null and b/docs/developing/verify_facilities/img/blockscout-6.png differ diff --git a/docs/developing/verify_facilities/img/blockscout-7.png b/docs/developing/verify_facilities/img/blockscout-7.png new file mode 100644 index 00000000..fce2fccf Binary files /dev/null and b/docs/developing/verify_facilities/img/blockscout-7.png differ diff --git a/docs/developing/verify_facilities/img/neonscan-1.png b/docs/developing/verify_facilities/img/neonscan-1.png new file mode 100644 index 00000000..7155b5c7 Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-1.png differ diff --git a/docs/developing/verify_facilities/img/neonscan-2.png b/docs/developing/verify_facilities/img/neonscan-2.png new file mode 100644 index 00000000..8dce7516 Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-2.png differ diff --git a/docs/developing/verify_facilities/img/neonscan-3.png b/docs/developing/verify_facilities/img/neonscan-3.png new file mode 100644 index 00000000..90361829 Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-3.png differ diff --git a/docs/developing/verify_facilities/img/neonscan-4.png b/docs/developing/verify_facilities/img/neonscan-4.png new file mode 100644 index 00000000..745b83fe Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-4.png differ diff --git a/docs/developing/verify_facilities/img/neonscan-5.png b/docs/developing/verify_facilities/img/neonscan-5.png new file mode 100644 index 00000000..fe5d432c Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-5.png differ diff --git a/docs/developing/verify_facilities/img/neonscan-6.png b/docs/developing/verify_facilities/img/neonscan-6.png new file mode 100644 index 00000000..ac0ae578 Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-6.png differ diff --git a/docs/developing/verify_facilities/img/neonscan-7.png b/docs/developing/verify_facilities/img/neonscan-7.png new file mode 100644 index 00000000..d0628eda Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-7.png differ diff --git a/docs/developing/verify_facilities/img/neonscan-8.png b/docs/developing/verify_facilities/img/neonscan-8.png new file mode 100644 index 00000000..9d5538b1 Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-8.png differ diff --git a/docs/developing/verify_facilities/using_foundry.md b/docs/developing/verify_facilities/using_foundry.md new file mode 100644 index 00000000..baf1fc75 --- /dev/null +++ b/docs/developing/verify_facilities/using_foundry.md @@ -0,0 +1,75 @@ +--- +title: Verify smart contracts with Foundry +proofedDate: na +iterationBy: na +includedInSite: true +approvedBy: na +comment: +--- + +_This page outlines the steps for verifying contracts on Neon EVM using the Foundry tool._ + +This tutorial is based on the example located in [this repository](https://github.com/neonlabsorg/neon-tutorials/tree/main/foundry). + +:::info +Foundry doesn't support custom explorers and only support Blockscout, Sourcify and Etherscan. +::: + +By the end of this tutorial, you will learn to verify a contract that deploys an ERC-20 token to Neon EVM Devnet on Blockscout explorer. + +## Step 1: Configure `.env` + +Create a `.env` file in the project's root directory to feed in the required variables. + +```sh +RPC_URL_DEVNET=https://devnet.neonevm.org +CHAIN_ID_DEVNET=245022926 +RPC_URL_MAINNET=https://neon-proxy-mainnet.solana.p2p.org +CHAIN_ID_MAINNET=245022934 +PRIVATE_KEY= +VERIFIER_URL_BLOCKSCOUT=https://neon-devnet.blockscout.com/api +``` + +Run `source .env` to save the .env variables. + +## Step 2: Deploy the contract + +To deploy a contract, please follow this page describing [how to deploy contracts with Foundry](https://docs.neonevm.org/docs/developing/deploy_facilities/using_foundry). + +## Step 3: Verify the deployed contract + +To verify the deployed contract from the above step, let's take an example of a deployed contract with address `0x93adb347065949a90a7f2e198f94c2fadeb7dbbd` on Neon EVM Devnet. + +After running the following command to verify - + +```sh +forge verify-contract --chain-id $CHAIN_ID_DEVNET 0x93adb347065949a90a7f2e198f94c2fadeb7dbbd src/TestERC20/TestERC20.sol:TestERC20 --verifier-url $VERIFIER_URL_BLOCKSCOUT --verifier blockscout +``` + +The output should look like this - + +```sh +Start verifying contract `0x93Adb347065949a90a7f2e198F94c2FADeb7dBbd` deployed on 245022926 + +Submitting verification for [src/TestERC20/TestERC20.sol:TestERC20] "0x93Adb347065949a90a7f2e198F94c2FADeb7dBbd". +Submitted contract for verification: + Response: `OK` + GUID: `93adb347065949a90a7f2e198f94c2fadeb7dbbd661584d8` + URL: + https://neon-devnet.blockscout.com/api?/address/0x93adb347065949a90a7f2e198f94c2fadeb7dbbd +``` + +The verified contract source code can be found here https://neon-devnet.blockscout.com/address/0x93Adb347065949a90a7f2e198F94c2FADeb7dBbd?tab=contract. + +:::important +If the deployed contract consists of constructor arguments to be passed, then the constructor arguments are ABI-encoded. For example - + +```sh +forge verify-contract --chain-id $CHAIN_ID_DEVNET 0x93adb347065949a90a7f2e198f94c2fadeb7dbbd src/TestERC20/TestERC20.sol:TestERC20 --verifier-url $VERIFIER_URL_BLOCKSCOUT --verifier blockscout --constructor-args $(cast abi-encode "constructor(string,string)" "TestToken" "TEST") +``` + +::: + +:::info +If you want to verify on NeonScan, then please follow this page which describes the steps **[to verify smart contracts manually on NeonScan](verify_manually.md)** +::: diff --git a/docs/developing/verify_facilities/using_hardhat.md b/docs/developing/verify_facilities/using_hardhat.md new file mode 100644 index 00000000..89db239d --- /dev/null +++ b/docs/developing/verify_facilities/using_hardhat.md @@ -0,0 +1,140 @@ +--- +title: Verify smart contracts with Hardhat +proofedDate: na +iterationBy: na +includedInSite: true +approvedBy: na +comment: +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +_This page outlines the steps for verifying contracts on Neon EVM using the Hardhat tool._ + +Before beginning the tutorial below, make sure that you have properly [configured Hardhat](/docs/developing/deploy_facilities/configure_hardhat) for Neon EVM. + +This tutorial is based on the example located in [this repository](https://github.com/neonlabsorg/neon-tutorials/tree/main/hardhat). + +By the end of this tutorial, you will learn to verify a contract that deploys an ERC-20 token to Neon EVM Devnet on Neonscan and Blockscout explorers. + +## Step 1: Deploy the contract + +To deploy a contract, please follow this page describing [how to deploy contracts with Hardhat](https://docs.neonevm.org/docs/developing/deploy_facilities/using_hardhat). + +## Step 2: Verify the deployed contract + +To verify the deployed contract from the above step, let's take an example of a deployed contract with address `0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08` on Neon EVM Devnet. + + + + +1. Add these lines to `hardhat.config.js` - + +```sh +etherscan: { + apiKey: { + neonevm: "test", + }, + customChains: [ + { + network: "neonevm", + chainId: 245022926, + urls: { + apiURL: "https://devnet-api.neonscan.org/hardhat/verify", + browserURL: "https://devnet.neonscan.org", + }, + }, + { + network: "neonevm", + chainId: 245022934, + urls: { + apiURL: "https://api.neonscan.org/hardhat/verify", + browserURL: "https://neonscan.org", + }, + }, + ], +}, +``` + +2. After running the following command to verify - + +```sh +npx hardhat verify --network neondevnet 0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08 +``` + +The output should look like this - + +```sh +Successfully submitted source code for contract +contracts/TestERC20/TestERC20.sol:TestERC20Hardhat at 0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08 +for verification on the block explorer. Waiting for verification result... + +Successfully verified contract TestERC20Hardhat on the block explorer. +https://devnet.neonscan.org/address/0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08#code +``` + +The verified contract source code can be found here https://devnet.neonscan.org/address/0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08#contract. + + + + + +1. Add these lines to `hardhat.config.js` - + +```sh +etherscan: { + apiKey: { + neonevm: "test", + }, + customChains: [ + { + network: "neonevm", + chainId: 245022926, + urls: { + apiURL: "https://neon-devnet.blockscout.com/api", + browserURL: "https://neon-devnet.blockscout.com", + }, + }, + { + network: "neonevm", + chainId: 245022934, + urls: { + apiURL: "https://neon.blockscout.com/api", + browserURL: "https://neon.blockscout.com", + }, + }, + ], +}, +``` + +2. After running the following command to verify - + +```sh +npx hardhat verify --network neondevnet 0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08 +``` + +The output should look like this - + +```sh +Successfully submitted source code for contract +contracts/TestERC20/TestERC20.sol:TestERC20Hardhat at 0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08 +for verification on the block explorer. Waiting for verification result... + +Successfully verified contract TestERC20Hardhat on the block explorer. +https://neon-devnet.blockscout.com/address/0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08#code +``` + +The verified contract source code can be found here https://neon-devnet.blockscout.com/address/0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08?tab=contract. + + + + +:::important +If the deployed contract consists of constructor arguments to be passed, then the command for verification should be - + +```sh +npx hardhat verify --network neondevnet +``` + +::: diff --git a/docs/developing/verify_facilities/verify_manually.md b/docs/developing/verify_facilities/verify_manually.md new file mode 100644 index 00000000..6543204c --- /dev/null +++ b/docs/developing/verify_facilities/verify_manually.md @@ -0,0 +1,171 @@ +--- +title: Verify smart contracts manually +proofedDate: na +iterationBy: na +includedInSite: true +approvedBy: na +comment: +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +_This page outlines the steps for verifying contracts on Neon EVM manually on NeonScan and Blockscout._ + +Before beginning the tutorial below, please follow this page which describes [how to deploy a smart contract on Neon EVM using Remix IDE](https://docs.neonevm.org/docs/developing/deploy_facilities/using_remix). + +If you are not using Hardhat or Foundry tools for deployment and using Remix for the smart contract development, then you can verify your smart contracts on NeonScan or Blockscout. + +## Step 1: Deploy the contract + +For this example, let us take a simple smart contract `TestERC20.sol` - + +```sh +// SPDX-License-Identifier: MIT +pragma solidity 0.8.24; + +import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; + +contract TestERC20Manual is ERC20 { + constructor() ERC20("TestERC20", "TST") { + _mint(msg.sender, 1000 * 10 ** decimals()); + } +} +``` + +## Step 2: Verify the deployed contract + +If your smart contract references different solidity files in its imports, you can upload a flattened version of the smart contract or upload each solidity file your smart contract references. + +To flatten your contract, right-click the filename on your Remix.IDE file explorer, and choose flatten. Remix.IDE will generate a flattened version of your smart contract e.g., TestERC20_flattened.sol in this case, that you can paste into NeonScan or Blockscout. + + + + +To verify the deployed contract from the above step, let's take an example of a deployed contract with address `0x628C8F52De7C661AA703523eDD75539Dce8D7EBB` on Neon EVM Devnet. + +The deployed contract can be found here https://devnet.neonscan.org/address/0x628C8F52De7C661AA703523eDD75539Dce8D7EBB#contract. + +1. Click on the `Verify Contract Code` link to go the verification page. + +
+ +![](img/neonscan-1.png) + +
+ +2. On the `Verify and Publish` page, the `Contract Address` field is auto-filled with the deployed contract address. + +
+ +![](img/neonscan-2.png) + +
+ +3. Enter the name of the deployed contract in the `Contract Name` field. In this example, the name of the deployed contract is **TestERC20Manual**. + +
+ +![](img/neonscan-3.png) + +
+ +4. Select the `Compiler Type` from the dropdown. In this example, this should be **Solidity**. + +
+ +![](img/neonscan-4.png) + +
+ +5. Select the `Compiler Version` from the dropdown. In this example, the compiler version used is **v0.8.23+commit.f704f362**. + +
+ +![](img/neonscan-5.png) + +
+ +6. Select `Optimization` from the dropdown and the `Run` value. In this example, optimization is **Yes** and the value is **200**. + +
+ +![](img/neonscan-6.png) + +
+ +7. Enter the name of the flattened smart contract in the `File name` field and the flattened solidity source code in the `Code` field. The file name in this example is **TestERC2_flattened.sol**. + +
+ +![](img/neonscan-7.png) + +
+ +8. After clicking on the `Submit` button, the verified contract source code can be seen on the contract page https://devnet.neonscan.org/address/0x628C8F52De7C661AA703523eDD75539Dce8D7EBB#contract. + +
+ +![](img/neonscan-8.png) + +
+ + + + + +To verify the deployed contract from the above step, let's take an example of a deployed contract with address `0x00407307F5eb91dFCC406E88618dB8aAE7d715B8` on Neon EVM Devnet. + +The deployed contract can be found here https://neon-devnet.blockscout.com/address/0x00407307F5eb91dFCC406E88618dB8aAE7d715B8?tab=contract. + +1. Click on `Verify & publish`. + +
+ +![](img/blockscout-1.png) + +
+ +2. On the `Verify & publish` page, choose Contract license from the dropdown. In this example, the license mentioned in the smart contract is MIT. + +
+ +![](img/blockscout-2.png) + +
+ +3. Choose verification method or compiler type from the dropdown. In this example, we are using Solidity (Flattened source code). + +
+ +![](img/blockscout-3.png) + +
+ +4. Choose compiler and the EVM version from the dropdowns. These fields should be entered as per the configuration in Remix IDE. In this example, we are using compiler **0.8.24+commit.e11b9ed9** and EVM version **default**. + +
+ +![](img/blockscout-4.png) + +
+ +5. Click on the Optimization enabled if it is enabled in Remix IDE. Enter the flattened solidity code in the Contract code box. + +
+ +![](img/blockscout-5.png) + +
+ +6. After clicking on the `Verify & publish` button, the verified contract source code can be seen on the contract page https://neon-devnet.blockscout.com/address/0x00407307F5eb91dFCC406E88618dB8aAE7d715B8?tab=contract. + +
+ +![](img/blockscout-6.png) +![](img/blockscout-7.png) + +
+ + + diff --git a/docs/evm_compatibility/code_compatibility_checklist.md b/docs/evm_compatibility/code_compatibility_checklist.md new file mode 100644 index 00000000..c2ca572b --- /dev/null +++ b/docs/evm_compatibility/code_compatibility_checklist.md @@ -0,0 +1,88 @@ +--- +title: 'Smart Contract Code Compatibility Checklist' +proofedDate: na +iterationBy: HB +includedInSite: false +approvedBy: na +comments: na +--- + +## Introduction + +This page details the smart contract code compatibility factors that determine whether the smart contracts are fully compatible with Neon EVM or not. + +## Smart contract compatibility factors + +The following are the factors that determine the smart contract code compatibility with Neon EVM and the alternative solutions - + +### Solidity Compiler version + +If the contracts are not clean fork like Uniswap V2 or Aave V2 and the solidity compiler is very old i.e. < 0.8.x, it is always recommended to upgrade to the latest stable solidity compiler version and re-run the tests. +:::info +Solidity version ≥ 0.8.25 is not supported currently because of the need to implement EIP-5656 and EIP-1153. It will be supported on Devnet and Mainnet soon. +::: + +### Usage of third-party protocols + +There shouldn't be any usage of third party protocols that are not currently supported on Neon EVM. + +### Usage of `block.number` and `block.timestamp` + +1. `block.timestamp` and `block.number` shouldn't be used as an array or mapping key. More details can be found [here](https://docs.neonevm.org/docs/evm_compatibility/overview#limitation-on-blocktimestamp--blocknumber-usage) + +2. `block.timestamp` and `block.number` shouldn't be used as an argument in `create2`(Deterministic deployments) since deterministic addresses are calculated based on the arguments provided. + +### Usage of non-reentrancy safe methods `transfer()` and `send()` + +`transfer()` and `send()` are not considered as reentrancy safe methods in Neon EVM. This is described [here](https://docs.neonevm.org/docs/evm_compatibility/overview#reentrancy-safe-approaches). It is recommended to use `call()` as an alternative for native token transfers. + +```sh +contract Vulnerable { + function withdraw(uint256 amount) external { + // This forwards 2300 gas, which may not be enough if the recipient + // is a contract and gas costs change. + msg.sender.transfer(amount); + } +} + +contract Fixed { + function withdraw(uint256 amount) external { + // This forwards all available gas. Be sure to check the return value! + (bool success, ) = msg.sender.call.value(amount)(""); + require(success, "Transfer failed."); + } +} +``` + +### Usage of unsupported OpCodes + +There shouldn't be any usage of unsupported opcodes - + +1. `gasleft()` or `gas()` +2. `block.coinbase` +3. `block.difficulty` / `block.prevrandao` +4. `block.gaslimit` +5. `block.basefee` +6. `selfdestruct` - The opCode behind this method will be deprecated soon. This can be mostly seen with the projects that uses [Seaport marketplace protocol](https://github.com/ProjectOpenSea/seaport/blob/main/contracts/zones/PausableZone.sol#L110). However, if `selfdestruct` is used only for tests/ mocks, this can be skipped. + +The details of the unsupported opcodes are described [here](https://docs.neonevm.org/docs/evm_compatibility/opcodes). + +### Usage of `multicall` methods + +The smart contracts having `multicall` methods that includes more than one address or migration methods to recreate state from another chain results in exceeding the 64 accounts limit. This situation can be avoided by calling these methods in batches. + +:::info +The restriction of 64 accounts doesn't translate directly to 64 addresses in Solidity. The limit may further decrease if there are additional internal calls between contracts. +::: + +### Emitting big events data + +Smart contracts shouldn't emit big data through events such as an array of bytes or strings or a single bytes or string variable through a `multicall` method, which eventually generates a big event log if there are a lot of multicall iterations. + +Every Solana transaction which corresponds to a particular Neon EVM transaction, subject to an event limit of 128K bytes. If the transaction execution is in iterative mode, each Solana transaction within this process maintains a 128K byte limit for event logs. + +If the data emitted by an event is more than 128K bytes, the transaction won't get reverted, but some of the event data won't be stored on-chain, causing some inconsistencies in the data stored. + +## Support + +Should you require further advice to help troubleshoot, create a ticket in the support-tickets channel in [Neon's Discord](https://discord.gg/neonevm). diff --git a/package.json b/package.json index a393f6a6..09ecf219 100644 --- a/package.json +++ b/package.json @@ -15,11 +15,11 @@ "typecheck": "tsc" }, "dependencies": { - "@docusaurus/core": "^3.1.1", - "@docusaurus/plugin-client-redirects": "^3.1.1", - "@docusaurus/plugin-google-analytics": "^3.1.1", - "@docusaurus/preset-classic": "^3.1.1", - "@docusaurus/theme-search-algolia": "^3.1.1", + "@docusaurus/core": "^3.2.1", + "@docusaurus/plugin-client-redirects": "^3.2.1", + "@docusaurus/plugin-google-analytics": "^3.2.1", + "@docusaurus/preset-classic": "^3.2.1", + "@docusaurus/theme-search-algolia": "^3.2.1", "@mdx-js/react": "^3.0.1", "algolia": "^0.0.0", "clsx": "^2.1.0", @@ -36,7 +36,7 @@ }, "devDependencies": { "@babel/plugin-transform-react-jsx": "^7.23.4", - "@docusaurus/module-type-aliases": "^3.1.1", + "@docusaurus/module-type-aliases": "^3.2.1", "@tsconfig/docusaurus": "^2.0.2", "typescript": "^5.3.3" }, diff --git a/sidebars.js b/sidebars.js index 383e5226..decd9a73 100644 --- a/sidebars.js +++ b/sidebars.js @@ -75,7 +75,8 @@ const sidebars = { 'developing/integrate/oracles/integrating_chainlink', 'developing/integrate/oracles/integrating_pyth', 'developing/integrate/middleware/the-graph', - 'developing/integrate/indexer/flair' + 'developing/integrate/indexer/flair', + 'developing/integrate/indexer/subsquid' ] }, { @@ -88,6 +89,15 @@ const sidebars = { 'developing/deploy_facilities/using_remix' ] }, + { + type: 'category', + label: 'Verify Contracts', + items: [ + 'developing/verify_facilities/using_hardhat', + 'developing/verify_facilities/using_foundry', + 'developing/verify_facilities/verify_manually' + ] + }, { type: 'category', label: 'Configure Dev Tools', @@ -109,6 +119,7 @@ const sidebars = { label: 'EVM Compatibility', items: [ 'evm_compatibility/overview', + 'evm_compatibility/code_compatibility_checklist', 'evm_compatibility/json_rpc_api_methods', 'evm_compatibility/opcodes', 'evm_compatibility/precompiles'