### Go: Start Exclusive Integration Test Network Source: https://github.com/0xsoniclabs/sonic/blob/main/tests/TESTING.md Demonstrates starting an exclusive integration test network for scenarios requiring specific network configurations like restarts, rule updates, epoch advancement, or multi-node setups. It includes updating network rules and advancing epochs. ```Go import ( "testing" "github.com/0xsoniclabs/sonic/tests" "github.com/stretchr/testify/require" ) func TestNetworkRule_Update(t *testing.T){ require := require.New(t) net := tests.StartIntegrationTestNet(t) current := tests.GetNetworkRules(t, net) modified := myRuleModifications(current) tests.UpdateNetworkRules(t, net, modified) AdvanceEpochAndWaitForBlocks(t, net) net.Restart() newConfig := tests.GetNetworkRules(t, net) require.Equal(modified, newConfig) } ``` -------------------------------- ### Solidity Contract Example Source: https://github.com/0xsoniclabs/sonic/blob/main/tests/TESTING.md An example of a simple Solidity contract named 'Counter' with an increment function. This contract is intended to be compiled and used with Go bindings generated by abigen. ```Solidity // SPDX-License-Identifier: MIT\npragma solidity ^0.8.20;\n\ncontract Counter {\n int private count = 0;\n\n function incrementCounter() public {\n count += 1;\n }\n} ``` -------------------------------- ### Go: Send Transactions Asynchronously via Client Source: https://github.com/0xsoniclabs/sonic/blob/main/tests/TESTING.md Demonstrates sending transactions asynchronously using a client obtained from a test session. It shows how to get a client, defer its closure, send multiple transactions without waiting for receipts, and then retrieve receipts. ```Go func TestSendTransaction_Asynchronously(t *testing.T){ session := getIntegrationTestNetSession(t, opera.GetSonicUpgrades()) chainId := session.GetChainId() client, err := session.GetClient() require.NoError(t, err) defer client.Close() hashes := hash[] for i := range 5 { tx := SetTransactionDefaults(t, session, &types.LegacyTx{}, session.GetSessionSponsor()) signedTx := SignTransaction(t, chainId, tx, session.GetSessionSponsor()) err := client.SendTransaction(t.Context(), signedTx) require.NoError(t, err, "failed to send transaction") hash = append(hash, signedTx.Hash()) } receipts, err := session.GetReceipts(hashes) require.NoError(t, err) require.Equal(t, len(receipts), len(hashes)) } ``` -------------------------------- ### Go: Send Legacy Transactions in Bulk Source: https://github.com/0xsoniclabs/sonic/blob/main/tests/TESTING.md Shows how to send multiple legacy transactions in bulk using an integration test session. It covers setting transaction defaults, signing transactions, and verifying their execution. ```Go func TestMultipleSessions_CanSendLegacyTransactionsInBulk(t *testing.T) { session := getIntegrationTestNetSession(t, opera.GetAllegroUpgrades()) chainId := session.GetChainId() txs := types.Transaction[]{} for i := range 5 { tx := SetTransactionDefaults(t, session, &types.LegacyTx{}, session.GetSessionSponsor()) signedTx := SignTransaction(t, chainId, tx, session.GetSessionSponsor()) txs = append(txs, signedTx) } receipts, err := session.RunAll(txs) require.NoError(t, err, "failed to send transaction") require.Equal(t, len(receipts), len(txs)) } ``` -------------------------------- ### Go Code Generation for Solidity Contracts Source: https://github.com/0xsoniclabs/sonic/blob/main/tests/TESTING.md Demonstrates the Go code generation process for Solidity contracts using `solc` and `abigen`. The `gen.go` file specifies commands to compile the contract's binary and ABI, then generate Go bindings. ```Go package mycontract\n\n//go:generate solc --bin mycontract.sol --abi mycontract.sol -o build --overwrite\n//go:generate abigen --bin=build/MyContract.bin --abi=build/MyContract.abi --pkg=mycontract --out=mycontract.go ``` -------------------------------- ### Install Solidity Compiler solc Source: https://github.com/0xsoniclabs/sonic/blob/main/tests/contracts/README.md This snippet shows how to install the `solc` compiler on Ubuntu using snap. The `solc` compiler is necessary for compiling Solidity smart contracts. ```bash sudo snap install solc --edge ``` -------------------------------- ### Start Sonic Network Source: https://github.com/0xsoniclabs/sonic/blob/main/demo/README.md Starts the Sonic private testing network with a specified number of genesis validators. The 'N' environment variable controls the number of validators. ```sh N=3 ./start.sh ``` -------------------------------- ### Run Sonic Integration Tests (Go) Source: https://github.com/0xsoniclabs/sonic/blob/main/tests/TESTING.md Executes the integration tests for the Sonic project using the Go testing framework. Includes a timeout flag to accommodate the longer execution time of these tests. ```go go test /path/to/0xSonicLabs/sonic/tests/... -timeout 30m ``` -------------------------------- ### Go: Parallelize Tests with t.Run and t.Parallel Source: https://github.com/0xsoniclabs/sonic/blob/main/tests/TESTING.md Illustrates how to structure integration tests for parallel execution using `t.Run` for sub-tests and `t.Parallel` for concurrency. It emphasizes spawning sessions within sub-tests to avoid race conditions. ```Go func TestType_ManyProperties(t *testing.T){ session := getIntegrationTestNetSession(t, opera.GetSonicUpgrades()) t.Run("someProperty", func (t *testing.T){ subSession := session.SpawnSession(t) t.Parallel() validateSomeProperty(t, session) }) t.Run("anotherProperty", func (t *testing.T){ subSession := session.SpawnSession(t) t.Parallel() validateAnotherProperty(t, session) }) } ``` -------------------------------- ### Go Memory Profiling Command Source: https://github.com/0xsoniclabs/sonic/blob/main/tests/TESTING.md Command to inspect heap memory usage reports generated by the Sonic test suite. It uses `go tool pprof` to visualize memory profiles, typically generated with the `SONIC_TEST_HEAP_PROFILE=on` environment variable. ```Shell go tool pprof -http "localhost:8000" build/profile/mem_myTestName.pprof ``` -------------------------------- ### Go Test for Counter Contract Integration Source: https://github.com/0xsoniclabs/sonic/blob/main/tests/TESTING.md A Go test function `TestCounter_CanIncrementAndReadCounterFromHead` that deploys a Counter contract, interacts with it by calling the increment function multiple times, and verifies the counter's value. ```Go func TestCounter_CanIncrementAndReadCounterFromHead(t *testing.T) {\n\n session := getIntegrationTestNetSession(t, opera.GetSonicUpgrades())\n t.Parallel()\n\n // Deploy the counter contract.\n contract, receipt, err := DeployContract(session, counter.DeployCounter)\n require.NoError(t, err, "failed to deploy contract; %v", err)\n require.Equal(t, receipt.Status, types.ReceiptStatusSuccessful)\n\n // Increment the counter a few times and check that the value is as expected.\n for i := 0; i < 10; i++ {\n counter, err := contract.GetCount(nil)\n require.NoError(t, err, "failed to get counter value")\n require.Equal(t, int64(i), counter.Int64(), "unexpected counter value")\n\n _, err = session.Apply(contract.IncrementCounter)\n require.NoError(t, err, "failed to apply increment counter contract")\n }\n} ``` -------------------------------- ### Get Node Balance (JS) Source: https://github.com/0xsoniclabs/sonic/blob/main/demo/README.md Retrieves the balance of an account on a Sonic node using the JavaScript console. It accesses the balance of the first account (eth.accounts[0]). ```js eth.getBalance(eth.accounts[0]); ``` -------------------------------- ### Get Node Address (CLI) Source: https://github.com/0xsoniclabs/sonic/blob/main/demo/README.md Retrieves the address of the first account on a specific Sonic node using the sonic-cli. This is useful for obtaining recipient addresses for transactions. ```sh ../build/sonictool --datadir=tool.datadir cli --exec "eth.accounts[0]" http://localhost:4001 ``` -------------------------------- ### Get Transaction Receipt (JS) Source: https://github.com/0xsoniclabs/sonic/blob/main/demo/README.md Retrieves the receipt of a previously sent transaction using its unique hash. This allows checking the transaction's inclusion in a block and its status. ```js eth.getTransactionReceipt("0x68a7c1daeee7e7ab5aedf0d0dba337dbf79ce0988387cf6d63ea73b98193adfd").blockNumber ``` -------------------------------- ### Initialize Sonic Database Source: https://github.com/0xsoniclabs/sonic/blob/main/README.md Initializes the Sonic database using a genesis file. Requires the sonictool executable and a path to the genesis file. ```Shell sonictool --datadir= genesis ``` -------------------------------- ### Run Sonic Node with Configuration File Source: https://github.com/0xsoniclabs/sonic/blob/main/README.md Launches a sonicd node using a specified configuration file. Requires a datadir path and the path to the config.toml file. ```Shell sonicd --datadir= --config /path/to/your/config.toml ``` -------------------------------- ### Build Sonic Source Code Source: https://github.com/0xsoniclabs/sonic/blob/main/README.md Builds the Sonic project executables (sonicd and sonictool) using a Makefile. Requires Go (1.24+) and a C compiler. ```Shell make all ``` -------------------------------- ### Generate Go Bindings with abigen Source: https://github.com/0xsoniclabs/sonic/blob/main/tests/contracts/README.md This snippet demonstrates how to generate Go bindings for smart contracts using the `abigen` tool. It requires the `abigen` executable, which is part of the go-ethereum project. ```bash go install github.com/ethereum/go-ethereum/cmd/abigen@latest ``` -------------------------------- ### Run Sonic Read-Only Node Source: https://github.com/0xsoniclabs/sonic/blob/main/README.md Launches a sonicd read-only node for a network specified by the genesis file. Requires a datadir path. ```Shell sonicd --datadir= ``` -------------------------------- ### Run Sonic Validator Node Source: https://github.com/0xsoniclabs/sonic/blob/main/README.md Launches a sonicd node configured as a validator. Requires a datadir path, validator ID, and validator public key. It will prompt for a password or can use a password file. ```Shell sonicd --datadir= --validator.id=YOUR_ID --validator.pubkey=0xYOUR_PUBKEY ``` -------------------------------- ### Run Sonic P2P Protocol Fuzzer Source: https://github.com/0xsoniclabs/sonic/blob/main/FUZZING.md This command initiates the fuzzing process for the Sonic project's p2p protocol. It is designed to find vulnerabilities in packages that parse complex inputs, particularly those handling data from untrusted sources. The fuzzer generates a `gossip-fuzz.zip` file in the `fuzzing/` directory upon successful execution. ```Shell make fuzz ``` -------------------------------- ### Dump Sonic Default Configuration Source: https://github.com/0xsoniclabs/sonic/blob/main/README.md Exports the default configuration for Sonic to be used in a config.toml file. Requires the sonictool executable and a datadir path. ```Shell sonictool --datadir= dumpconfig ``` -------------------------------- ### Create New Sonic Validator Key Source: https://github.com/0xsoniclabs/sonic/blob/main/README.md Generates a new private key for a Sonic validator. Requires the sonictool executable and a datadir path. ```Shell sonictool --datadir= validator new ``` -------------------------------- ### Improve Sonic Node Connectivity Source: https://github.com/0xsoniclabs/sonic/blob/main/README.md Configures the sonicd node to specify its public IP for better peer discovery. Requires a datadir path and the external IP address. ```Shell sonicd --datadir= --nat=extip:1.2.3.4 ``` -------------------------------- ### Attach to Sonic Node CLI Source: https://github.com/0xsoniclabs/sonic/blob/main/demo/README.md Attaches a JavaScript console to a running Sonic node for interactive commands. It requires the path to the sonictool executable and the node's RPC endpoint. ```sh ../build/sonictool --datadir=tool.datadir cli http://localhost:4000 ``` -------------------------------- ### Sonic Fuzzer Output Log Source: https://github.com/0xsoniclabs/sonic/blob/main/FUZZING.md This log displays the real-time output from the Sonic p2p protocol fuzzer. It provides metrics such as the number of active workers, the size of the corpus (valid inputs found), the count of detected crashes, the number of restarts, execution rate, code coverage, and the total uptime of the fuzzer. This information is crucial for monitoring the fuzzing process and identifying potential issues. ```Log 2020/12/30 22:50:51 workers: 0, corpus: 1 (3s ago), crashers: 0, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 3s 2020/12/30 22:50:54 workers: 0, corpus: 1 (6s ago), crashers: 0, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 6s 2020/12/30 22:50:57 workers: 3, corpus: 1 (9s ago), crashers: 0, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 9s 2020/12/30 22:51:00 workers: 3, corpus: 1 (12s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 12s 2020/12/30 22:51:03 workers: 3, corpus: 1 (15s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 15s 2020/12/30 22:51:06 workers: 3, corpus: 1 (18s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 18s 2020/12/30 22:51:09 workers: 3, corpus: 1 (21s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 21s 2020/12/30 22:51:12 workers: 3, corpus: 1 (24s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 24s 2020/12/30 22:51:15 workers: 3, corpus: 1 (27s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 27s 2020/12/30 22:51:18 workers: 3, corpus: 1 (30s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 30s 2020/12/30 22:51:21 workers: 3, corpus: 1 (33s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 33s 2020/12/30 22:51:24 workers: 3, corpus: 1 (36s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 36s 2020/12/30 22:51:27 workers: 3, corpus: 1 (39s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 39s 2020/12/30 22:51:30 workers: 3, corpus: 1 (42s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 42s ``` -------------------------------- ### Check Balances After Transaction (CLI) Source: https://github.com/0xsoniclabs/sonic/blob/main/demo/README.md Checks the balances of accounts on different Sonic nodes after a transaction has been processed. This verifies the successful transfer of funds. ```sh ../build/sonictool --datadir=tool.datadir cli --exec "eth.getBalance(eth.accounts[0])" http://localhost:4000 ``` ```sh ../build/sonictool --datadir=tool.datadir cli --exec "eth.getBalance(eth.accounts[0])" http://localhost:4001 ``` -------------------------------- ### Send Balance Transfer Transaction (JS) Source: https://github.com/0xsoniclabs/sonic/blob/main/demo/README.md Initiates a balance transfer transaction from one account to another on the Sonic network. It specifies the sender, receiver address, and the amount to transfer. ```js eth.sendTransaction( {"from": eth.accounts[0], "to": "0x02aff1d0a9ed566e644f06fcfe7efe00a3261d03", "value": "1000000000"}, function(err, transactionHash) { if (!err) console.log(transactionHash + " success"); }); ``` === COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.