fix(examples): use correct verifyBatchInclusion function and update python scripts on examples/verify

[JuArce]

Use correct verifyBatchInclusion function and update python scripts on examples/verify

Description

The example available in examples/verify uses the deprecated verifyBatchInclusion function which does not receive senderAddress. It should use the following function

function verifyBatchInclusion(
        bytes32 proofCommitment,
        bytes32 pubInputCommitment,
        bytes32 provingSystemAuxDataCommitment,
        bytes20 proofGeneratorAddr,
        bytes32 batchMerkleRoot,
        bytes memory merkleProof,
        uint256 verificationDataBatchIndex,
        address senderAddress
    ) external view onlyWhenNotPaused(2) returns (bool) {
...
}

Also, the python scripts to generate the verification data does not work. It uses an old version of the encoded data file.

How to Test

There are two cases to test, the first one is using cURL and the second one is using a Python script.

For both cases, there are some common steps:

1. Run aligned locally

make anvil_start_with_block_time

make batcher_start_local

make aggregator_start ENVIRONMENT=devnet

make operator_full_registration CONFIG_FILE=config-files/config-operator-1.yaml ENVIRONMENT=devnet
make operator_start CONFIG_FILE=config-files/config-operator-1.yaml ENVIRONMENT=devnet

2. Send some proofs

make batcher_send_burst_groth16

With send some proofs is enough. We need to use one of the verification data files received after the creation of the task

Proofs verification data should be available in ./aligned_verification_data/

For example,

b8c17406_0.cbor
b8c17406_0.json

3. Deploy a contract who will call to AlignedServiceManager to check the batch inclusion of your sent proofs

cd examples/verify

Complete the .env with the following values

PRIVATE_KEY=0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6
RPC_URL=http://localhost:8545
ALIGNED_DEPLOYMENT_OUTPUT=../../contracts/script/output/devnet/alignedlayer_deployment_output.json

Then run

./scripts/deploy_verify_batch_inclusion_caller.sh

This will output the address of the deployed contract. You will need this address to interact with the contract.

In my case it is 0xA15BB66138824a1c7167f5E85b957d04Dd34E468

4. Install Python dependencies

pip3 install -r requirements.txt

Use case 1: Using cURL to check the verification

1. Encode the data from the .json file

python3 encode_verification_data.py --aligned-verification-data ../../aligned_verification_data/b8c17406_0.json --sender-address 0x7bc06c482DEAd17c0e297aFbC32f6e63d3846650

Note: You need to change b8c17406_0.json with your json file

2. Call to Ethereum using cURL

curl -X POST http://localhost:8545 \
-H "Content-Type: application/json" \
-d '{
    "jsonrpc": "2.0",
    "method": "eth_call",
    "params": [{
        "to": "<CONTRACT_ADDRESS>",
        "data": "<CALLDATA>"
    }],
    "id": 1
}'

In this case we replace CONTRACT_ADDRESS with 0xA15BB66138824a1c7167f5E85b957d04Dd34E468 and CALLDATA with the output of step 1.

The output should be as follow

{"jsonrpc":"2.0","id":1,"result":"0x0000000000000000000000000000000000000000000000000000000000000001"}

The result: 0x0000000000000000000000000000000000000000000000000000000000000001 means it was verified in Aligned

Use case 2: Using a Python script to check the verification

1. Run the script with

python3 verify.py --contract-address 0xA15BB66138824a1c7167f5E85b957d04Dd34E468 --aligned-verification-data ../../aligned_verification_data/b8c17406_0.json --sender-address 0x7bc06c482DEAd17c0e297aFbC32f6e63d3846650 --rpc-url http://localhost:8545

Replace --contract-address with your deployed contract and --aligned-verification-data with your proof data. --sender-address is the Devnet BatcherPaymentService contract.

It should return

Submitted proof with associated data is verified in ethereum blockchain

Type of change

• Bug fix

close #1795

Checklist

• “Hotfix” to testnet, everything else to staging
• Linked to Github Issue
• This change depends on code or research by an external entity
  • Acknowledgements were updated to give credit
• Unit tests added
• This change requires new documentation.
  • Documentation has been added/updated.
• This change is an Optimization
  • Benchmarks added/run
• Has a known issue
  • Link to the open issue addressing it
• If your PR changes the Operator compatibility (Ex: Upgrade prover versions)
  • This PR adds compatibility for operator for both versions and do not change batcher/docs/examples
  • This PR updates batcher and docs/examples to the newer version. This requires the operator are already updated to be compatible