From 715ec0a2f70879aa5155a95fdf069dad9b08cda5 Mon Sep 17 00:00:00 2001 From: Jennifer Echenim Date: Tue, 3 Sep 2024 02:08:00 +0400 Subject: [PATCH] Update naming from "Ten" to "TEN" --- .../manual-deploy-obscuro-gateway.yml | 70 +++++------ .../workflows/manual-deploy-ten-bridge.yml | 4 +- .../manual-deploy-ten-gateway-frontend.yml | 56 ++++----- .../manual-deploy-testnet-validator.yml | 112 +++++++++--------- README.md | 50 ++++---- changelog.md | 16 +-- contracts/README.md | 8 +- contracts/src/README.md | 2 +- design/README.md | 8 +- design/architecture/overall_design.md | 16 +-- design/bridge/bridge_design.md | 48 ++++---- .../Soft_finality_guarantee.md | 12 +- design/finality_protocol/fast_finality.md | 6 +- .../sequencer_bootstrapping_strategy.md | 8 +- design/gateway/gateway_caching.md | 4 +- design/security/Escape_hatch.md | 4 +- design/security/Source_of_truth.md | 32 ++--- design/security/Upgrade_Design.md | 28 ++--- design/security/high_availability.md | 8 +- design/security/randomness_design.md | 4 +- design/ux/Events_design.md | 20 ++-- design/ux/Ten_Gateway.md | 32 ++--- design/ux/block_explorer.md | 8 +- design/ux/user_data_incentives.md | 6 +- design/ux/wallet_extension.md | 18 +-- developer_onboarding_guide.md | 4 +- dockerfiles/README.md | 8 +- go/common/gethencoding/geth_encoding.go | 2 +- go/common/headers.go | 2 +- go/config/enclave_config.go | 2 +- go/enclave/evm/README.md | 2 +- go/enclave/l2chain/README.md | 2 +- go/enclave/rpc/README.md | 4 +- go/enclave/storage/enclavedb/README.md | 4 +- .../storage/init/edgelessdb/edgelessdb.go | 8 +- go/host/container/cli_flags.go | 2 +- go/host/rpc/clientapi/client_api_ten.go | 4 +- go/node/README.md | 2 +- go/obsclient/README.md | 8 +- go/rpc/README.md | 4 +- go/rpc/client.go | 2 +- go/rpc/encrypted_client.go | 2 +- integration/README.md | 2 +- integration/networktest/env/network_setup.go | 6 +- integration/noderunner/noderunner_test.go | 2 +- .../simulation/devnetwork/dev_network.go | 20 ++-- .../simulation/network/geth_network.go | 4 +- integration/simulation/network/inmemory.go | 2 +- integration/simulation/network/network.go | 8 +- .../simulation/network/network_utils.go | 2 +- .../simulation/network/obscuro_node_utils.go | 16 +-- integration/simulation/network/socket.go | 8 +- .../simulation/p2p/in_mem_obscuro_client.go | 2 +- integration/simulation/params/params.go | 2 +- integration/simulation/simulation.go | 6 +- integration/simulation/validate_chain.go | 8 +- integration/tengateway/tengateway_test.go | 6 +- integration/tenscan/tenscan_test.go | 6 +- lib/gethfork/README.MD | 2 +- lib/gethfork/log/format.go | 2 +- planning/Testnet release plan.md | 2 +- planning/testnet-kpis.md | 16 +-- testnet/launcher/docker.go | 8 +- tools/bridge-frontend/README.md | 2 +- tools/bridge-frontend/pages/index.tsx | 4 +- tools/faucet/README.md | 10 +- tools/gateway-js/gateway-lib/README.md | 6 +- tools/hardhatdeployer/README.md | 4 +- tools/tenscan/frontend/public/docs/terms.json | 4 +- .../components/modules/personal/columns.tsx | 4 +- tools/walletextension/README.md | 6 +- .../frontend/public/docs/terms.json | 4 +- .../frontend/public/favicon/site.webmanifest | 4 +- .../src/components/modules/home/connected.tsx | 4 +- .../components/modules/home/disconnected.tsx | 22 ++-- .../frontend/src/lib/constants.ts | 14 ++- .../frontend/src/services/ethService.ts | 13 +- .../src/services/useGatewayService.ts | 16 +-- tools/walletextension/lib/README.md | 2 +- tools/walletextension/main/cli.go | 2 +- .../walletextension/rpcapi/blockchain_api.go | 4 +- tools/walletextension/rpcapi/debug_api.go | 2 +- .../rpcapi/wallet_extension.go | 8 +- tools/walletextension/rpcapi/web3_api.go | 2 +- 84 files changed, 455 insertions(+), 454 deletions(-) diff --git a/.github/workflows/manual-deploy-obscuro-gateway.yml b/.github/workflows/manual-deploy-obscuro-gateway.yml index 3a29807a72..040ebd4bca 100644 --- a/.github/workflows/manual-deploy-obscuro-gateway.yml +++ b/.github/workflows/manual-deploy-obscuro-gateway.yml @@ -1,34 +1,34 @@ -# Deploys Ten Gateway on Azure for Testnet -# Builds the Ten Gateway image, pushes the image to dockerhub and starts the Ten Gateway on Azure VM +# Deploys TEN Gateway on Azure for Testnet +# Builds the TEN Gateway image, pushes the image to dockerhub and starts the TEN Gateway on Azure VM -name: '[M] Deploy Ten Gateway Backend' -run-name: '[M] Deploy Ten Gateway Backend ( ${{ github.event.inputs.testnet_type }} )' +name: "[M] Deploy TEN Gateway Backend" +run-name: "[M] Deploy TEN Gateway Backend ( ${{ github.event.inputs.testnet_type }} )" on: workflow_dispatch: inputs: testnet_type: - description: 'Environment' + description: "Environment" required: true - default: 'dev-testnet' + default: "dev-testnet" type: choice options: - - 'dev-testnet' - - 'uat-testnet' - - 'sepolia-testnet' + - "dev-testnet" + - "uat-testnet" + - "sepolia-testnet" instance_type: - description: 'Instance' + description: "Instance" required: true - default: 'primary' + default: "primary" type: choice options: - - 'primary' - - 'dexynth' + - "primary" + - "dexynth" jobs: validate-inputs: runs-on: ubuntu-latest steps: - - name: 'Check if deployment is allowed' + - name: "Check if deployment is allowed" run: | if [[ "${{ github.event.inputs.instance_type }}" == "Dexynth" && "${{ github.event.inputs.testnet_type }}" != "sepolia-testnet" ]]; then echo "Error: Dexynth can only be deployed to sepolia-testnet." @@ -40,20 +40,20 @@ jobs: environment: name: ${{ github.event.inputs.testnet_type }} steps: - - name: 'Set up environment variables' + - name: "Set up environment variables" id: setup_env run: | INSTANCE_SUFFIX="" INSTANCE_PREFIX="" - + if [[ "${{ github.event.inputs.instance_type }}" != "primary" ]]; then INSTANCE_SUFFIX="-${{ github.event.inputs.instance_type }}" INSTANCE_PREFIX="${{ github.event.inputs.instance_type }}-" fi - + echo "INSTANCE_SUFFIX=$INSTANCE_SUFFIX" >> $GITHUB_ENV echo "INSTANCE_PREFIX=$INSTANCE_PREFIX" >> $GITHUB_ENV - + # Set infrastructure variables PUBLIC_IP="${{ github.event.inputs.testnet_type }}-OG-static${INSTANCE_SUFFIX}" DNS_NAME="obscurogateway-${{ github.event.inputs.testnet_type }}${INSTANCE_SUFFIX}" @@ -61,14 +61,14 @@ jobs: DEPLOY_GROUP="ObscuroGateway-${{ github.event.inputs.testnet_type }}-${{ github.run_number }}${INSTANCE_SUFFIX}" VNET_NAME="ObscuroGateway-${{ github.event.inputs.testnet_type }}-01VNET${INSTANCE_SUFFIX}" SUBNET_NAME="ObscuroGateway-${{ github.event.inputs.testnet_type }}-01Subnet${INSTANCE_SUFFIX}" - + echo "PUBLIC_IP=$PUBLIC_IP" >> $GITHUB_ENV echo "DNS_NAME=$DNS_NAME" >> $GITHUB_ENV echo "VM_NAME=$VM_NAME" >> $GITHUB_ENV echo "DEPLOY_GROUP=$DEPLOY_GROUP" >> $GITHUB_ENV echo "VNET_NAME=$VNET_NAME" >> $GITHUB_ENV echo "SUBNET_NAME=$SUBNET_NAME" >> $GITHUB_ENV - + # Set instance-specific variables declare -a VAR_NAMES=( "DOCKER_BUILD_TAG_GATEWAY" @@ -78,7 +78,7 @@ jobs: "GATEWAY_RATE_LIMIT_WINDOW" "GATEWAY_MAX_CONCURRENT_REQUESTS_PER_USER" ) - + for VAR_NAME in "${VAR_NAMES[@]}"; do FULL_VAR_NAME="${INSTANCE_PREFIX}${VAR_NAME}" VAR_VALUE=$(jq -r --arg key "$FULL_VAR_NAME" '.[$key] // empty' <<< '${{ toJson(vars) }}') @@ -89,7 +89,7 @@ jobs: fi done - - name: 'Print environment variables' + - name: "Print environment variables" # This is a useful record of what the environment variables were at the time the job ran, for debugging and reference run: | echo "INSTANCE_SUFFIX: $INSTANCE_SUFFIX" @@ -107,30 +107,30 @@ jobs: echo "GATEWAY_RATE_LIMIT_WINDOW: $GATEWAY_RATE_LIMIT_WINDOW" echo "GATEWAY_MAX_CONCURRENT_REQUESTS_PER_USER: $GATEWAY_MAX_CONCURRENT_REQUESTS_PER_USER" - - name: 'Print GitHub variables' + - name: "Print GitHub variables" # This is a useful record of what the environment variables were at the time the job ran, for debugging and reference run: | echo "GitHub Variables = ${{ toJSON(vars) }}" - uses: actions/checkout@v4 - - name: 'Extract branch name' + - name: "Extract branch name" shell: bash run: | echo "Branch Name: ${GITHUB_REF_NAME}" echo "BRANCH_NAME=${GITHUB_REF_NAME}" >> $GITHUB_ENV - - name: 'Set up Docker' + - name: "Set up Docker" uses: docker/setup-buildx-action@v1 - - name: 'Login to Azure docker registry' + - name: "Login to Azure docker registry" uses: azure/docker-login@v1 with: login-server: testnetobscuronet.azurecr.io username: testnetobscuronet password: ${{ secrets.REGISTRY_PASSWORD }} - - name: 'Login via Azure CLI' + - name: "Login via Azure CLI" uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }} @@ -141,26 +141,26 @@ jobs: docker push ${{ env.DOCKER_BUILD_TAG_GATEWAY }} # This will fail some deletions due to resource dependencies ( ie. you must first delete the vm before deleting the disk) - - name: 'Delete deployed VMs' + - name: "Delete deployed VMs" uses: azure/CLI@v1 with: inlineScript: | $(az resource list --tag ${{ env.AZURE_DEPLOY_GROUP_GATEWAY }}=true --query '[]."id"' -o tsv | xargs -n1 az resource delete --verbose -g Testnet --ids) || true # This will clean up any lingering dependencies - might fail if there are no resources to cleanup - - name: 'Delete VMs dependencies' + - name: "Delete VMs dependencies" uses: azure/CLI@v1 with: inlineScript: | $(az resource list --tag ${{ env.AZURE_DEPLOY_GROUP_GATEWAY }}=true --query '[]."id"' -o tsv | xargs -n1 az resource delete --verbose -g Testnet --ids) || true - - name: 'Ensure VM Static Public IP Exists' + - name: "Ensure VM Static Public IP Exists" uses: azure/CLI@v1 with: inlineScript: | az network public-ip show -g Testnet -n "${{ env.PUBLIC_IP }}" || az network public-ip create -g Testnet -n "${{ env.PUBLIC_IP }}" --allocation-method Static --sku Standard - - name: 'Assign/Update DNS Name for Public IP' + - name: "Assign/Update DNS Name for Public IP" uses: azure/CLI@v1 with: inlineScript: | @@ -169,7 +169,7 @@ jobs: az network public-ip update -g Testnet -n "${{ env.PUBLIC_IP }}" --dns-name "${{ env.DNS_NAME }}" fi - - name: 'Create VM for Gateway node on Azure' + - name: "Create VM for Gateway node on Azure" uses: azure/CLI@v1 with: inlineScript: | @@ -181,18 +181,18 @@ jobs: --size Standard_D4_v5 --image Canonical:0001-com-ubuntu-server-focal:20_04-lts-gen2:latest \ --authentication-type password - - name: 'Open Ten node-${{ matrix.host_id }} ports on Azure' + - name: "Open TEN node-${{ matrix.host_id }} ports on Azure" uses: azure/CLI@v1 with: inlineScript: | az vm open-port -g Testnet -n "${{ env.VM_NAME }}" --port 80,81 # To overcome issues with critical VM resources being unavailable, we need to wait for the VM to be ready - - name: 'Allow time for VM initialization' + - name: "Allow time for VM initialization" shell: bash run: sleep 30 - - name: 'Start Ten Gateway on Azure' + - name: "Start TEN Gateway on Azure" uses: azure/CLI@v1 with: inlineScript: | diff --git a/.github/workflows/manual-deploy-ten-bridge.yml b/.github/workflows/manual-deploy-ten-bridge.yml index 14b51c7529..facec2937c 100644 --- a/.github/workflows/manual-deploy-ten-bridge.yml +++ b/.github/workflows/manual-deploy-ten-bridge.yml @@ -1,5 +1,5 @@ -# Deploys Ten Bridge on Azure for Testnet -# Builds the Ten Bridge image, pushes the image to dockerhub and starts the Ten Bridge on Azure +# Deploys TEN Bridge on Azure for Testnet +# Builds the TEN Bridge image, pushes the image to dockerhub and starts the TEN Bridge on Azure name: "[M] Deploy Bridge Testnet" run-name: "[M] Deploy Bridge Testnet ( ${{ github.event.inputs.testnet_type }} )" diff --git a/.github/workflows/manual-deploy-ten-gateway-frontend.yml b/.github/workflows/manual-deploy-ten-gateway-frontend.yml index e3fe12fc0b..532c504b42 100644 --- a/.github/workflows/manual-deploy-ten-gateway-frontend.yml +++ b/.github/workflows/manual-deploy-ten-gateway-frontend.yml @@ -1,33 +1,33 @@ -# Deploys Ten Gateway Frontend on Azure for Testnet -# Builds the Ten Gateway image, pushes the image to dockerhub and starts the Ten Gateway on Azure VM +# Deploys TEN Gateway Frontend on Azure for Testnet +# Builds the TEN Gateway image, pushes the image to dockerhub and starts the TEN Gateway on Azure VM -name: '[M] Deploy Ten Gateway Frontend' -run-name: '[M] Deploy Ten Gateway Frontend ( ${{ github.event.inputs.testnet_type }} )' +name: "[M] Deploy TEN Gateway Frontend" +run-name: "[M] Deploy TEN Gateway Frontend ( ${{ github.event.inputs.testnet_type }} )" on: workflow_dispatch: inputs: testnet_type: - description: 'Testnet Type' + description: "Testnet Type" required: true - default: 'dev-testnet' + default: "dev-testnet" type: choice options: - - 'dev-testnet' - - 'uat-testnet' - - 'sepolia-testnet' + - "dev-testnet" + - "uat-testnet" + - "sepolia-testnet" instance_type: - description: 'Instance' + description: "Instance" required: true - default: 'primary' + default: "primary" type: choice options: - - 'primary' - - 'dexynth' + - "primary" + - "dexynth" jobs: validate-inputs: runs-on: ubuntu-latest steps: - - name: 'Check if deployment is allowed' + - name: "Check if deployment is allowed" run: | if [[ "${{ github.event.inputs.instance_type }}" == "dexynth" && "${{ github.event.inputs.testnet_type }}" != "sepolia-testnet" ]]; then echo "Error: Dexynth can only be deployed to sepolia-testnet." @@ -38,33 +38,33 @@ jobs: environment: name: ${{ github.event.inputs.testnet_type }} steps: - - name: 'Set up environment variables' + - name: "Set up environment variables" id: setup_env run: | INSTANCE_SUFFIX="" INSTANCE_PREFIX="" - + if [[ "${{ github.event.inputs.instance_type }}" != "primary" ]]; then INSTANCE_SUFFIX="-${{ github.event.inputs.instance_type }}" INSTANCE_PREFIX="${{ github.event.inputs.instance_type }}-" fi - + echo "INSTANCE_SUFFIX=$INSTANCE_SUFFIX" >> $GITHUB_ENV echo "INSTANCE_PREFIX=$INSTANCE_PREFIX" >> $GITHUB_ENV - - + + DNS_NAME_LABEL_GATEWAY_FE="${{ github.event.inputs.testnet_type }}-ten-gateway${INSTANCE_SUFFIX}" IMAGE_NAME_GATEWAY_FE="${{ github.event.inputs.testnet_type }}-fe-ten-gateway${INSTANCE_SUFFIX}" - + echo "DNS_NAME_LABEL_GATEWAY_FE=$DNS_NAME_LABEL_GATEWAY_FE" >> $GITHUB_ENV echo "IMAGE_NAME_GATEWAY_FE=$IMAGE_NAME_GATEWAY_FE" >> $GITHUB_ENV - + # Set instance-specific variables declare -a VAR_NAMES=( "DOCKER_BUILD_TAG_GATEWAY_FE" "GATEWAY_URL" ) - + for VAR_NAME in "${VAR_NAMES[@]}"; do FULL_VAR_NAME="${INSTANCE_PREFIX}${VAR_NAME}" VAR_VALUE=$(jq -r --arg key "$FULL_VAR_NAME" '.[$key] // empty' <<< '${{ toJson(vars) }}') @@ -74,8 +74,8 @@ jobs: echo "Warning: ${FULL_VAR_NAME} not found in vars" >&2 fi done - - - name: 'Print GitHub variables' + + - name: "Print GitHub variables" run: | echo "Selected Testnet Type: ${{ github.event.inputs.testnet_type }}" echo "Selected Instance Type: ${{ github.event.inputs.instance_type }}" @@ -86,23 +86,23 @@ jobs: - uses: actions/checkout@v4 - - name: 'Extract branch name' + - name: "Extract branch name" shell: bash run: | echo "Branch Name: ${GITHUB_REF_NAME}" echo "BRANCH_NAME=${GITHUB_REF_NAME}" >> $GITHUB_ENV - - name: 'Set up Docker' + - name: "Set up Docker" uses: docker/setup-buildx-action@v3.6.1 - - name: 'Login to Azure docker registry' + - name: "Login to Azure docker registry" uses: azure/docker-login@v1 with: login-server: testnetobscuronet.azurecr.io username: testnetobscuronet password: ${{ secrets.REGISTRY_PASSWORD }} - - name: 'Login via Azure CLI' + - name: "Login via Azure CLI" uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }} diff --git a/.github/workflows/manual-deploy-testnet-validator.yml b/.github/workflows/manual-deploy-testnet-validator.yml index cda3c96da4..11d8f5d847 100644 --- a/.github/workflows/manual-deploy-testnet-validator.yml +++ b/.github/workflows/manual-deploy-testnet-validator.yml @@ -1,4 +1,4 @@ -# Deploys a Ten validator on Azure for Testnet +# Deploys a TEN validator on Azure for Testnet # # This script uses GitHub Environments for variables (vars) and secrets - these are configured on GitHub and # the environments match the input.testnet_type options @@ -19,56 +19,54 @@ # Node Account Address: is the Account Address of the ADD_NEW_NODE_PRIVATE_KEY # -name: '[M] Deploy Testnet Validator' -run-name: '[M] Deploy Testnet Validator ( ${{ github.event.inputs.testnet_type }} )' +name: "[M] Deploy Testnet Validator" +run-name: "[M] Deploy Testnet Validator ( ${{ github.event.inputs.testnet_type }} )" on: workflow_dispatch: inputs: testnet_type: - description: 'Testnet Type' + description: "Testnet Type" required: true - default: 'dev-testnet' + default: "dev-testnet" type: choice options: - - 'dev-testnet' - - 'uat-testnet' - - 'sepolia-testnet' + - "dev-testnet" + - "uat-testnet" + - "sepolia-testnet" log_level: - description: 'Log Level 1-Error 5-Trace' + description: "Log Level 1-Error 5-Trace" required: true default: 3 type: number node_id: - description: 'Node id' + description: "Node id" required: true type: string node_account_address: - description: 'Node Account Address' + description: "Node Account Address" required: true type: string MGMT_CONTRACT_ADDR: - description: 'Management Contract Addr' + description: "Management Contract Addr" required: true type: string MSG_BUS_CONTRACT_ADDR: - description: 'Message bus Contract Addr' + description: "Message bus Contract Addr" required: true type: string L1_START_HASH: - description: 'L1 Starting Hash' + description: "L1 Starting Hash" required: true type: string - jobs: build: runs-on: ubuntu-latest environment: name: ${{ github.event.inputs.testnet_type }} - steps: - - name: 'Print GitHub variables' + - name: "Print GitHub variables" # This is a useful record of what the environment variables were at the time the job ran, for debugging and reference run: | echo "GitHub Variables = ${{ toJSON(vars) }}" @@ -79,19 +77,19 @@ jobs: with: go-version: 1.21.8 - - name: 'Login via Azure CLI' + - name: "Login via Azure CLI" uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }} - - name: 'Login to Azure docker registry' + - name: "Login to Azure docker registry" uses: azure/docker-login@v1 with: login-server: testnetobscuronet.azurecr.io username: testnetobscuronet password: ${{ secrets.REGISTRY_PASSWORD }} - - name: 'Build and push obscuro node images' + - name: "Build and push obscuro node images" run: | DOCKER_BUILDKIT=1 docker build -t ${{ vars.DOCKER_BUILD_TAG_ENCLAVE }} --build-arg TESTMODE=true -f dockerfiles/enclave.Dockerfile . docker push ${{ vars.DOCKER_BUILD_TAG_ENCLAVE }} @@ -106,20 +104,19 @@ jobs: environment: name: ${{ github.event.inputs.testnet_type }} - steps: - - name: 'Extract branch name' + - name: "Extract branch name" shell: bash run: | echo "Branch Name: ${GITHUB_REF_NAME}" echo "BRANCH_NAME=${GITHUB_REF_NAME}" >> $GITHUB_ENV - - name: 'Login via Azure CLI' + - name: "Login via Azure CLI" uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }} - - name: 'Create VM for Obscuro node-${{ github.event.inputs.node_id }} on Azure' + - name: "Create VM for Obscuro node-${{ github.event.inputs.node_id }} on Azure" uses: azure/CLI@v1 with: inlineScript: | @@ -131,18 +128,18 @@ jobs: --size Standard_DC8_v2 --storage-sku StandardSSD_LRS --image ObscuroConfUbuntu \ --public-ip-sku Standard --authentication-type password - - name: 'Open Obscuro node-${{ github.event.inputs.host_id }} ports on Azure' + - name: "Open Obscuro node-${{ github.event.inputs.host_id }} ports on Azure" uses: azure/CLI@v1 with: inlineScript: | az vm open-port -g Testnet -n "${{ vars.AZURE_RESOURCE_PREFIX }}-${{ github.event.inputs.node_id }}-${{ GITHUB.RUN_NUMBER }}" --port 80,81,6060,6061,10000 # To overcome issues with critical VM resources being unavailable, we need to wait for the VM to be ready - - name: 'Allow time for VM initialization' + - name: "Allow time for VM initialization" shell: bash run: sleep 60 - - name: 'Start Obscuro node-${{ github.event.inputs.node_id }} on Azure' + - name: "Start Obscuro node-${{ github.event.inputs.node_id }} on Azure" uses: azure/CLI@v1 with: inlineScript: | @@ -190,37 +187,36 @@ jobs: -postgres_db_host=postgres://tenuser:${{ secrets.TEN_POSTGRES_USER_PWD }}@postgres-ten-${{ github.event.inputs.testnet_type }}.postgres.database.azure.com:5432/ \ start' - -# -# Load Balancer can't be updated until the L1 and L2 is bootstrapped -# -# update-loadbalancer: -# needs: -# - check-obscuro-is-healthy -# runs-on: ubuntu-latest -# environment: -# name: ${{ github.event.inputs.testnet_type }} -# steps: -# - uses: actions/checkout@v4 -# -# - name: 'Login via Azure CLI' -# uses: azure/login@v1 -# with: -# creds: ${{ secrets.AZURE_CREDENTIALS }} -# -# - name: 'Remove existing backend nodes from the load balancer' -# run: ./.github/workflows/runner-scripts/testnet-clear-loadbalancer.sh ${{ github.event.inputs.testnet_type }} -# -# - name: 'Add load balancer address pool to the IP configuration' -# uses: azure/CLI@v1 -# with: -# inlineScript: | -# az network nic ip-config address-pool add \ -# --address-pool ${{ github.event.inputs.testnet_type }}-backend-pool \ -# --ip-config-name ipconfig${{ vars.AZURE_RESOURCE_PREFIX }}-${{ github.event.inputs.node_id }}-${{ GITHUB.RUN_NUMBER }} \ -# --nic-name ${{ vars.AZURE_RESOURCE_PREFIX }}-${{ github.event.inputs.node_id }}-${{ GITHUB.RUN_NUMBER }}VMNic \ -# --resource-group Testnet \ -# --lb-name ${{ github.event.inputs.testnet_type }}-loadbalancer + # + # Load Balancer can't be updated until the L1 and L2 is bootstrapped + # + # update-loadbalancer: + # needs: + # - check-obscuro-is-healthy + # runs-on: ubuntu-latest + # environment: + # name: ${{ github.event.inputs.testnet_type }} + # steps: + # - uses: actions/checkout@v4 + # + # - name: 'Login via Azure CLI' + # uses: azure/login@v1 + # with: + # creds: ${{ secrets.AZURE_CREDENTIALS }} + # + # - name: 'Remove existing backend nodes from the load balancer' + # run: ./.github/workflows/runner-scripts/testnet-clear-loadbalancer.sh ${{ github.event.inputs.testnet_type }} + # + # - name: 'Add load balancer address pool to the IP configuration' + # uses: azure/CLI@v1 + # with: + # inlineScript: | + # az network nic ip-config address-pool add \ + # --address-pool ${{ github.event.inputs.testnet_type }}-backend-pool \ + # --ip-config-name ipconfig${{ vars.AZURE_RESOURCE_PREFIX }}-${{ github.event.inputs.node_id }}-${{ GITHUB.RUN_NUMBER }} \ + # --nic-name ${{ vars.AZURE_RESOURCE_PREFIX }}-${{ github.event.inputs.node_id }}-${{ GITHUB.RUN_NUMBER }}VMNic \ + # --resource-group Testnet \ + # --lb-name ${{ github.event.inputs.testnet_type }}-loadbalancer check-obscuro-is-healthy: needs: diff --git a/README.md b/README.md index 7c07a3db16..9dcc8019b8 100644 --- a/README.md +++ b/README.md @@ -14,14 +14,14 @@ The typical blockchain node runs multiple services in a single process. For exam - Mempool - etc -Ten uses Trusted Execution Environments (TEE), like Intel SGX, to execute transactions in a confidential environment, which means we diverge from the typical architecture. +TEN uses Trusted Execution Environments (TEE), like Intel SGX, to execute transactions in a confidential environment, which means we diverge from the typical architecture. There are three main components of the architecture, each running as a separate process: the Enclave, the Host and the Wallet Extension. ![Architecture](design/architecture/resources/obscuro_arch.jpeg) ### I. The Enclave -This is the core component of Ten which runs inside the TEE. +This is the core component of TEN which runs inside the TEE. See [go/enclave](go/enclave) We use [EGo](https://www.edgeless.systems/products/ego/), an open source SDK for developing this confidential component. @@ -31,7 +31,7 @@ The Enclave exposes an [interface](go/common/enclave.go) over RPC which attempts The Enclave component has these main responsibilities: #### 1. Execute EVM transactions -Ten has the goal to be fully compatible with the EVM, so smart contracts can be ported freely from other EVM compatible +TEN has the goal to be fully compatible with the EVM, so smart contracts can be ported freely from other EVM compatible chains. To achieve this and minimise the effort and incompatibilities, we depend on [go-ethereum](https://github.com/ethereum/go-ethereum). The dependency on go-ethereum is not straight forward, since transaction execution is coupled with Ethereum specific consensus rules, @@ -59,7 +59,7 @@ See [go/enclave/db](go/enclave/db) #### 3. Consume Ethereum blocks The Enclave is fed Ethereum blocks through the RPC interface. These blocks are used as the "Source of Truth", and the Enclave extracts useful information from them, such as published rollups, deposits to the bridge, etc. Ethereum re-orgs have to be detected -at this level to rollback the Ten state accordingly. +at this level to rollback the TEN state accordingly. To avoid the risk of the Enclave being fed invalid blocks which an attacker can use to probe for information, or to shorten the [revelation period](https://whitepaper.ten.xyz/ten-whitepaper/detailed-design.html#revelation-mechanism), the blocks have to be checked for validity, which includes checking that enough "work" went into them. @@ -70,20 +70,20 @@ logic. #### 4. Bridge to Ethereum One of the key aspects of Ethereum Layer 2 (L2) solutions is to feature a decentralised bridge that is resistant to 51% attacks. -Ten features a L2 side of the bridge that is completely under the control of the platform. +TEN features a L2 side of the bridge that is completely under the control of the platform. ##### a) Deposits During processing of the Ethereum blocks, the platform generates synthetic L2 transactions based on every relevant transaction found there. -For example when Alice deposits 10ABC from her account to the L1 bridge, Ten will execute a synthetic L2 transaction (that it deterministically +For example when Alice deposits 10ABC from her account to the L1 bridge, TEN will execute a synthetic L2 transaction (that it deterministically generated from the L1 transaction), which moves 10WABC from the L2 bridge to Alice's address on Ten. This logic is part of the consensus of Ten, every node receiving the same block containing the rollup and the deposits, will generate the exact same synthetic transaction. ##### b) Withdrawals -Ten ERC20 transactions sent to a special "Bridge" address are interpreted as withdrawals. Which means the wrapped tokens are burned -on the Ten side of the bridge and a Withdrawal instruction is added to the rollup header, which will be later executed by the Ethereum side of the bridge. +TEN ERC20 transactions sent to a special "Bridge" address are interpreted as withdrawals. Which means the wrapped tokens are burned +on the TEN side of the bridge and a Withdrawal instruction is added to the rollup header, which will be later executed by the Ethereum side of the bridge. -This happens deterministically in a post-processing phase, after all Ten transactions were executed by the EVM. +This happens deterministically in a post-processing phase, after all TEN transactions were executed by the EVM. See [go/enclave/bridge](go/enclave/bridge) @@ -109,7 +109,7 @@ included in a rollup.* #### 6. The rollups and the PoBI protocol Like in any blockchain the unit of the protocol is the batch of transactions organized in a chain. -The Ten blocks have an encrypted payload, which is only visible inside the secure Enclave. +The TEN blocks have an encrypted payload, which is only visible inside the secure Enclave. All of the logic of maintaining the current state based on incoming data and of producing new rollups is found in the [go/enclave/rollupchain](go/enclave/rollupchain) package. @@ -123,13 +123,13 @@ These are the main components: ##### a) RPC encryption/decryption -The Ten "Wallet extension" encrypts all requests from users (transactions or smart contract method calls) with the "Ten public key", which is a key derived from the +The TEN "Wallet extension" encrypts all requests from users (transactions or smart contract method calls) with the "TEN public key", which is a key derived from the master seed. The response is in turn encrypted with the "Viewing Key" of the requesting user. This component manages viewing keys and handles the encryption and decryption. -The transactions received from users are gossiped with the other aggregators encrypted with the "Ten Public Key". +The transactions received from users are gossiped with the other aggregators encrypted with the "TEN Public Key". *Note: In the current implementation, this key is hardcoded.* @@ -181,7 +181,7 @@ building blocks of the Enclave* The missing link to achieving fully private transactions while allowing end-users to continue using their favourite wallets (like MetaMask). This is a very thin component that is responsible for encrypting and decrypting traffic -between the Ten node and its clients. +between the TEN node and its clients. See the [docs](https://docs.ten.xyz/wallet-extension/wallet-extension/) for more information. @@ -197,17 +197,17 @@ root │ ├── enclave: The component that is loaded up inside SGX. │ │ ├── bridge: The platform side of the decentralised bridge logic. │ │ ├── core: Base data structures used only inside the enclave. -│ │ ├── crypto: Implementation of the Ten cryptography. +│ │ ├── crypto: Implementation of the TEN cryptography. │ │ ├── db: The database implementations. │ │ ├── enclaverunner: The entry point to the standalone enclave process. -│ │ ├── evm: Ten transaction execution on top of the EVM. +│ │ ├── evm: TEN transaction execution on top of the EVM. │ │ ├── main: Main │ │ ├── mempool: The mempool living inside the enclave │ │ ├── rollupchain: The main logic for calculating the state and the POBI protocol. │ │ └── rpcencryptionmanager: Responsible for encrypting the communication with the wallet extension. │ ├── ethadapter: Responsible for interpreting L1 transactions │ │ ├── erc20contractlib: Understand ERC20 transactions. -│ │ └── mgmtcontractlib: Understand Ten Management contrract transactions. +│ │ └── mgmtcontractlib: Understand TEN Management contrract transactions. │ ├── host: The standalone host process. │ │ ├── db: The host's database. │ │ ├── hostrunner: The entry point. @@ -220,28 +220,28 @@ root │ │ └── enclaverpc: The RPC client for communications with the enclave. │ ├── rpcclientlib: Library to allow go applications to connect to a host via RPC. │ └── wallet: Logic around wallets. Used both by the node, which is an ethereum wallet, and by the tests -├── integration: Integration tests that spin up Ten networks. +├── integration: Integration tests that spin up TEN networks. │ ├── simulation: A series of tests that simulate running networks with different setups. ├── testnet: Utilities for deploying a testnet. └── tools: Peripheral tooling. ├── hardhatdeployer: Automates deployment of ERC20 and management contracts to the L1. ├── faucet: Faucet for testnet. ├── tenscan: Tooling to monitor network transactions. - └── walletextension: Ensures sensitive messages to and from the Ten node are encrypted. + └── walletextension: Ensures sensitive messages to and from the TEN node are encrypted. ## Testing -The Ten integration tests are found in: [integration/simulation](integration/simulation). +The TEN integration tests are found in: [integration/simulation](integration/simulation). The main tests are "simulations", which means they spin up both an L1 network and an L2 network, and then inject random transactions. Due to the non-determinism of both the "mining" protocol in the L1 network and the nondeterminism of POBI, coupled with the random traffic, it allows the tests to capture many corner cases without having to explicitly write individual tests for them. The first [simulation_in_mem_test](integration/simulation/simulation_in_mem_test.go) runs fully in one single process on top of a -mocked L1 network and with the networking components of the Ten node swapped out, and is just focused on producing +mocked L1 network and with the networking components of the TEN node swapped out, and is just focused on producing random L1 blocks at very short intervals. The [ethereummock](integration/ethereummock) implementation is based on the ethereum protocol with the individual nodes gossiping with each other with random latencies, producing blocks at a random interval distributed around a configured ``AvgBlockDuration``, and making decisions about the canonical head based on the longest chain. @@ -255,7 +255,7 @@ The [simulation_geth_in_mem_test](integration/simulation/simulation_geth_in_mem_ network of geth nodes started in clique mode. The lowest unit of time of producing blocks in that mode is `1 second`. The [simulation_full_network_test](integration/simulation/simulation_full_network_test.go) starts standalone local processes for -both the enclave and the ten node connected to real geth nodes. +both the enclave and the TEN node connected to real geth nodes. The [simulation_docker_test](integration/simulation/simulation_docker_test.go) goes a step further and runs the enclave in "Simulation mode" in a docker container with the "EGo" library. @@ -269,8 +269,8 @@ of these setups by receiving RPC handles to the nodes. ## Getting Started -The following section describes building the reference implementation of the Ten protocol, running the unit and -integration tests, and deploying a local testnet for end-to-end testing. The reference implementation of Ten is +The following section describes building the reference implementation of the TEN protocol, running the unit and +integration tests, and deploying a local testnet for end-to-end testing. The reference implementation of TEN is written in [go](https://go.dev). Unless otherwise stated, all paths stated herein are relative to the root of the `go-ten` checkout. @@ -303,7 +303,7 @@ is used and the creation of the docker images automated as described in [Buildin ### Running the tests -The tests require an Ten enclave to be locally running, and as such the image should first be created and added to the +The tests require an TEN enclave to be locally running, and as such the image should first be created and added to the docker images repository. Building the image is described in [dockerfiles](dockerfiles) and can be performed using the below in the root of the project; @@ -329,7 +329,7 @@ go run ./testnet/launcher/cmd ``` The network is started running both a sequencer and a validator node (SGX simulated). It will also start a faucet server -to fund accounts on the network, and a local instance of the Ten Gateway to mediate connections to the network. The +to fund accounts on the network, and a local instance of the TEN Gateway to mediate connections to the network. The faucet server is started on `http://127.0.0.1:99` and the gateway on `http://127.0.0.1:3000`. To request funds for a given account use the below command; diff --git a/changelog.md b/changelog.md index f687f7d2ab..e0a0c4174f 100644 --- a/changelog.md +++ b/changelog.md @@ -57,7 +57,7 @@ * `c6e5a48f` Adds log constraints to docker containers not instantiated by the go client (#1956) * `85e6cd0d` Ignore empty l1 head status from enclave (#1955) * `a9485fef` Fixes for ethereum bridge and json representation of batch header (#1953) - * `e6453082` Deploy separate ten gateway for dexynth (#1949) + * `e6453082` Deploy separate TEN gateway for dexynth (#1949) * `b8935c31` Network tests: util func for l1 transfers (#1948) * `0f3d42bf` Network tests: start gateway synchronously to fix race (#1947) * `9cee2fd4` Increase max message size grpc config (#1946) @@ -97,7 +97,7 @@ handling capabilities of the gateway. * `cf7158ff` Postgres host config to upgrade script (#1913) * `6476895e` Reconnect new heads (#1910) * `42dc7f8a` Tweak performance (#1912) - * `596ddf02` Create separate deployment for ten gateway frontend (#1909) + * `596ddf02` Create separate deployment for TEN gateway frontend (#1909) * `1ec62e87` Db performance (#1893) * `6c12e168` Network tests: new heads subscriptions (#1907) * `1bb752fd` Wire edgeless in simulation mode for local testnet (#1905) @@ -163,7 +163,7 @@ handling capabilities of the gateway. * `74cfe0e5` Protocol: attest against enclaveid rather than hostid (#1831) * `75f610d4` Headers: use 65-byte signatures instead of r,s values (#1834) * `1e781f77` Network tests: basic sim to run in ci builds (#1833) - * `99315295` Use ten hardhat plugin instead of baked in registration (#1812) + * `99315295` Use TEN hardhat plugin instead of baked in registration (#1812) * `b52a7a49` Updated batch size limit (#1830) * `6083d1e1` Store incoming transactions in a database (#1828) * `057276df` Networktests: run local gateway against testnets (#1824) @@ -201,7 +201,7 @@ handling capabilities of the gateway. * `3a74586b` Change mempool validation function (#1800) * `597cf0ec` Change log for the v0.22 release (#1799) * `a2a080aa` Gateway caching proposal (#1773) - * `5b5e7d98` Ten gateway caching (#1779) + * `5b5e7d98` TEN gateway caching (#1779) * `7792864a` Adjust port offset (#1798) * `1837bcc6` More flakiness fixes (#1795) * `83469ca8` Validator nodes return error on tx submission (#1792) @@ -233,7 +233,7 @@ handling capabilities of the gateway. * `206dbffc` [gas mechanics] implement gas history; migrate to arbitrum gas model (#1714) * `0fe01b4e` Mempool perf fix (#1752) * `843d6cbb` 2 validators deploy (#1750) - * `dcf96c93` Ten gateway use http instead of ws (#1743) + * `dcf96c93` TEN gateway use http instead of ws (#1743) * `b49b4c0d` Loggers: use log format rather than terminal format for files (#1751) * `01980954` Remove old docs (#1749) * `7f0ad72b` Refactor testnet status update (#1748) @@ -286,9 +286,9 @@ handling capabilities of the gateway. * `dbfa7a30` Revert deleting favicon (#1691) * `b2651ab3` [gateway] Front end fixes for non-mm users (#1690) * `b428c62f` [gateway] Remove listener for account change (#1689) - * `b2ddee04` Deploy new ten gateway frontend (#1686) + * `b2ddee04` Deploy new TEN gateway frontend (#1686) * `2fa60897` Use the 3.18 go alpine image (#1687) (#1688) - * `d9ead96a` Ten gateway (#1657) + * `d9ead96a` TEN gateway (#1657) * `0fd37731` Rpc ap ensure hash field included in batches json (#1684) * `ca7f91b2` Adding enclave restricted flags (#1668) * `4551c81b` Enclave no panic for bad rlp format (#1679) @@ -321,7 +321,7 @@ handling capabilities of the gateway. * `0b47af67` Added another promote to admin. (#1651) * `309b2405` Replacing github links (#1647) * `0ec2d053` Rebranding .md files (#1648) - * `bb3a2bd2` Ui: replace obscuro logos with ten (#1649) + * `bb3a2bd2` Ui: replace obscuro logos with TEN (#1649) * `35b5ce45` Change base url to https (#1644) * `ef01370c` Adding geths mempool (#1639) * `82488783` Fix test ports (#1642) diff --git a/contracts/README.md b/contracts/README.md index af108faa7a..376a5b92e2 100644 --- a/contracts/README.md +++ b/contracts/README.md @@ -1,6 +1,6 @@ -# Ten smart contracts +# TEN smart contracts -This hardhat project contains the relevant smart contracts for the Ten L2 platform. +This hardhat project contains the relevant smart contracts for the TEN L2 platform. ## Dependencies @@ -32,13 +32,13 @@ Additionally you can pass the `noCompile` flag which will disable running the co ### Deployment Scripts folder structure - * core - Scripts required to be predeployed for Ten to start. + * core - Scripts required to be predeployed for TEN to start. * bridge - Scripts that deploy/upgrade ONLY the bridge. * messenger - Scripts that enable the relayer functionality. Can contain predeployed libraries too in the future. * testnet - Scripts that should only be deployed on the testnet. Tokens, "dev tooling" scripts, etc. For deployments, we use the hardhat-deploy plugin. It provides the `deploy` task, which determines what folders with deployment scripts need to be executed for the current selected network. Additionally there is the `ten:deploy` task that will launch a wallet extension. -For the wallet extension to work, the network needs to have configured the `url` to 127.0.0.1:3000 and the additional `tenEncRpcUrl` property to the rpc endpoint of the ten node the wallet will connect to. +For the wallet extension to work, the network needs to have configured the `url` to 127.0.0.1:3000 and the additional `tenEncRpcUrl` property to the rpc endpoint of the TEN node the wallet will connect to. Scripts are taken from `deployment_scripts` and executed in alphabetic order. Each folder, as ordered in the network config and then inside of it alphabetically. Notice that `func.dependencies = []` defined in deployment functions has the ability to escape the default ordering. If such a deployment function/script is reached, the deploy plugin will first deploy its dependency if it hasn't already. diff --git a/contracts/src/README.md b/contracts/src/README.md index 5c858ab6b8..c7a7f9698f 100644 --- a/contracts/src/README.md +++ b/contracts/src/README.md @@ -1,7 +1,7 @@ ## Solidity smart contracts In this subdirectory you can find the solidity smart contracts for the platform. -Under the `/management` subdirectory you can find the root contract of Ten - ManagementContract.sol +Under the `/management` subdirectory you can find the root contract of TEN - ManagementContract.sol It dictates the possible state of the Layer 2 and drives the process. Under `/messaging` you can find the cross chain messaging contracts. Inside of it under the `/messenger` subdirectory sits an example implementation of cross chain message relayer that utilizes the message bus. diff --git a/design/README.md b/design/README.md index c0cf65e9d5..a308d0a999 100644 --- a/design/README.md +++ b/design/README.md @@ -1,6 +1,6 @@ -# Ten design documents +# TEN design documents -Ten started based on a (whitepaper)[https://whitepaper.ten.xyz/] published in Nov. 2021. +TEN started based on a (whitepaper)[https://whitepaper.ten.xyz/] published in Nov. 2021. As we started development, we started thinking more deeply about some aspects and also getting feedback from the community and the users. @@ -25,7 +25,7 @@ Note: the wallet extension and the data relevancy rules are already implemented. ## Bridge -Ten needs a decentralised bridge infrastructure to Ethereum. +TEN needs a decentralised bridge infrastructure to Ethereum. Note: this design is approved and mostly implemented (there are some dependencies on the fast-finality work). @@ -40,7 +40,7 @@ Note: the design is approved, and currently it is being implemented. ## Security, Privacy and Cryptography -Ten is a decentralised Ethereum Layer 2 that aims to maintain privacy. +TEN is a decentralised Ethereum Layer 2 that aims to maintain privacy. We need to design the cryptography that keeps data private. Like any software system, it needs to be upgradeable, which is more difficult with our constraints. diff --git a/design/architecture/overall_design.md b/design/architecture/overall_design.md index 54c11442f7..3bdc2813a7 100644 --- a/design/architecture/overall_design.md +++ b/design/architecture/overall_design.md @@ -1,24 +1,24 @@ -# Ten design +# TEN design ## Scope The purpose of this document is to describe aspects of Ten's technical design that are not addressed in the -[Ten whitepaper](https://whitepaper.ten.xyz/). +[TEN whitepaper](https://whitepaper.ten.xyz/). ## Overview -The following diagram shows the key components of an Ten deployment: +The following diagram shows the key components of an TEN deployment: ![architecture diagram](./resources/obscuro_arch.jpeg) The Ethereum node and Ethereum chain components shown in this diagram are developed and maintained by third-parties. The following additional components must be developed: -* **The enclave:** The trusted part of the Ten node that runs inside a trusted execution environment (TEE) -* **The host:** The remainder of the Ten node that runs outside the TEE -* **The Ten management contract:** The Ethereum mainnet contracts required by the Ten protocol, described +* **The enclave:** The trusted part of the TEN node that runs inside a trusted execution environment (TEE) +* **The host:** The remainder of the TEN node that runs outside the TEE +* **The TEN management contract:** The Ethereum mainnet contracts required by the TEN protocol, described [here](https://whitepaper.ten.xyz/ten-whitepaper/l1-contracts) -* **Client apps:** Applications that interact with the Ten node (e.g. Ten wallets) +* **Client apps:** Applications that interact with the TEN node (e.g. TEN wallets) ## Host/enclave split @@ -50,7 +50,7 @@ The host has a lot of responsibilities, including: - serving requests for data and transaction submissions - feeding data to the enclave to keep it up-to-date with the L1 and L2 networks - publishing secret request/responses and (for the sequencer) rollups to the L1 network -- receiving and publishing Ten data (e.g. batches and mempool transactions) with peer nodes +- receiving and publishing TEN data (e.g. batches and mempool transactions) with peer nodes - managing failover and recovery for the enclave for high-availability (HA) nodes The host will be organised with a variety of services to manage these responsibilities. diff --git a/design/bridge/bridge_design.md b/design/bridge/bridge_design.md index ef5a40ce03..dc09372175 100644 --- a/design/bridge/bridge_design.md +++ b/design/bridge/bridge_design.md @@ -1,10 +1,10 @@ -# Ten Cross Chain Messaging And Initial Bridge - Design Document +# TEN Cross Chain Messaging And Initial Bridge - Design Document We want to expose a system API that allows any developer to come and build a bridge on Ten. We also want this API to support all types of well known bridges - wrapping assets, liquidity bridges, etc. And ideally we want the system API to further allow even more exotic type of apps - providing randomness to the L1, hidden game state and anything other that can be enabled as a cross chain application! With the API we will build an initial bridge that wraps assets and might progress this further. -The API design proposal is inspired by the [Wormhole protocol](https://wormhole.com/). The idea is we would allow for authenticated messaging between Layer 1 and Layer 2 on Ten through a smart contract API available on both layers. +The API design proposal is inspired by the [Wormhole protocol](https://wormhole.com/). The idea is we would allow for authenticated messaging between Layer 1 and Layer 2 on TEN through a smart contract API available on both layers. It will be provided by two smart contracts deployed on network creation on both layers. These contracts will be owned by the ManagementContract and the enclave on their respective layers. @@ -13,7 +13,7 @@ These contracts will be owned by the ManagementContract and the enclave on their ## Requirements 1. **High Level Requirements** - * The Ten platform provides On-Chain system APIs that allow dApp developers to build cross-chain bridges and applications. + * The TEN platform provides On-Chain system APIs that allow dApp developers to build cross-chain bridges and applications. * Users should be able to transmit authenticated data between L1 & L2. Example Message: ```json { @@ -23,20 +23,20 @@ These contracts will be owned by the ManagementContract and the enclave on their } ``` * As an L2 developer I want to be able to query specific message topics coming from specific addresses. - * The Ten gas calculation should include the L1 fees of submitting a message that originates on the L2. Users should fully cover the storage fees and the Rollup publisher should not incur any financial loss. + * The TEN gas calculation should include the L1 fees of submitting a message that originates on the L2. Users should fully cover the storage fees and the Rollup publisher should not incur any financial loss. * The messaging and bridge are decentralized as much as possible. * Block reorganizations should have no impact on the security of the messaging protocol and the downstream apps that use this protocol. 2. **Bridge Requirements** * The reference bridge contracts should be completely ordinary and separate from the management contract; The API should expose all the messaging pieces of information required in order to build the bridge independently from Ten - * The bridge will have an asset whitelist controlled and configured by the management contract. Later this will be managed by the Ten DAO. + * The bridge will have an asset whitelist controlled and configured by the management contract. Later this will be managed by the TEN DAO. * Assets and their wrapped L2 counterparts should be mapped and exposed for querying. * Bridge functionality should be able to use the [pull payment](https://docs.openzeppelin.com/contracts/2.x/api/payment#PullPayment) design. - > If any current dApps want to extend or port their functionality on Ten then it should be possible for them to do it without collaborating with anyone else + > If any current dApps want to extend or port their functionality on TEN then it should be possible for them to do it without collaborating with anyone else ## Scope -* Messaging architecture between Ten and Mainnet Ethereum. +* Messaging architecture between TEN and Mainnet Ethereum. * Basic Bridge that wraps assets * Primitive fees implementation @@ -44,11 +44,11 @@ These contracts will be owned by the ManagementContract and the enclave on their 1. Fees * Big assumption - there will be a way to pay for bridge services/messaging in TEN without incurring losses in ETH on the layer 1 side. - * The Ten DAO will be able to configure properties for the messaging part of the protocol and accurately estimate the `gas costs` of storing data without losing too much on `gas price` spikes. + * The TEN DAO will be able to configure properties for the messaging part of the protocol and accurately estimate the `gas costs` of storing data without losing too much on `gas price` spikes. 2. Finality * The management contract will be responsible for not exposing data that has not been finalized. This means that it should have first gone through the challenge period. * The Rollup protocol will ensure the L1 blocks being consumed by the enclave and the resulting synthetic transactions are always bound to the blocks generating them. - * Ten has fast finality over the transaction ordering rather than the results. When a deposit gets reorganized the results on Ten L2 should reorganize too if depending on it. + * TEN has fast finality over the transaction ordering rather than the results. When a deposit gets reorganized the results on TEN L2 should reorganize too if depending on it. ## Modifications @@ -57,9 +57,9 @@ The Rollup headers right now are assumed to include withdrawal instructions. The ## Definitions -* `System contract` - A contract that is deployed by the Ten protocol when the Layer 2 network is created. System contracts serve the purpose of providing system API access on-chain. +* `System contract` - A contract that is deployed by the TEN protocol when the Layer 2 network is created. System contracts serve the purpose of providing system API access on-chain. -## MessageBus Design - Ten cross-chain data transmission +## MessageBus Design - TEN cross-chain data transmission The `MessageBus` will be deployed as a [`Proxy`](https://docs.openzeppelin.com/contracts/4.x/api/proxy) @@ -129,7 +129,7 @@ Any contract or user can call the `publishMessage` function. Any message passed `consistencyLevel` is a mechanism to introduce delay before the message is considered valid. The platform will only expose the message after the block producing it is confirmed by blocks equal to the `consistencyLevel` -> **_NOTE:_** `consistencyLevel` is only required if Ten does not reorganize when L1 deposits reorganize. In other instances it can be set to 0 or 1. There is however another use case for it described in [Security](#MessageBusSecurity). +> **_NOTE:_** `consistencyLevel` is only required if TEN does not reorganize when L1 deposits reorganize. In other instances it can be set to 0 or 1. There is however another use case for it described in [Security](#MessageBusSecurity). ### Verify Message @@ -152,7 +152,7 @@ Internally, the function will hash the message and compare it with the result of ### Submit Out Of Network Messages -This is the smart contract function which is used to store messages sent from the other linked layer. The function will be called by the `ManagementContract` on L1 and the `enclave` on L2. It should be access controlled and called according to the `consistencyLevel` and Ten platform rules. +This is the smart contract function which is used to store messages sent from the other linked layer. The function will be called by the `ManagementContract` on L1 and the `enclave` on L2. It should be access controlled and called according to the `consistencyLevel` and TEN platform rules. ```solidity function submitOutOfNetworkMessage( @@ -164,7 +164,7 @@ function submitOutOfNetworkMessage( ) public onlyRole(ADMINISTRATOR|OWNER) ``` -This function should not be callable by any users or contracts unless they have the `ADMINISTRATOR` role or are the `Owner` of the `MessageBus` contract. Along with those requirements, on the Ten layer 2, there is an additional security measure - Any incoming transaction to this function is blocked, even if it is coming from an address that has the correct role. The protocol will block transactions that do not originate from inside of the enclave due to consuming L1 blocks. This means that even if the enclave gets hacked and the keys leak the verifiers will block withdraws. +This function should not be callable by any users or contracts unless they have the `ADMINISTRATOR` role or are the `Owner` of the `MessageBus` contract. Along with those requirements, on the TEN layer 2, there is an additional security measure - Any incoming transaction to this function is blocked, even if it is coming from an address that has the correct role. The protocol will block transactions that do not originate from inside of the enclave due to consuming L1 blocks. This means that even if the enclave gets hacked and the keys leak the verifiers will block withdraws. When called, the function should store the message indexed in storage - map of `senders` that contains a map of `topics` which points to array of `messages` should be sufficient. Along with it, the hash of the whole message should be used as a key to store a message received flag inside the map `receivedMessages`. This map enables quick verification that a message is valid and received. @@ -198,29 +198,29 @@ When a transaction on the `L2` results in `LogMessagePublished`, the event will ![Diagram not found](./resources/PublishFromTen.svg) -> **_NOTE:_** **The messages must not be accessible unless** the challenge period has passed! On top of that the block where the message is submitted to L1 must have confirmations equal to `consistencyLevel` before the message is released. Those are simply counted on-chain as "confirmations" is meaningless for Ten L2. +> **_NOTE:_** **The messages must not be accessible unless** the challenge period has passed! On top of that the block where the message is submitted to L1 must have confirmations equal to `consistencyLevel` before the message is released. Those are simply counted on-chain as "confirmations" is meaningless for TEN L2. ### Alternative approaches -1. Ten only ever pushes the hash of the message. The user has the responsibility of providing the full message which will only be accepted if it matches one of the hashes, if necessary. +1. TEN only ever pushes the hash of the message. The user has the responsibility of providing the full message which will only be accepted if it matches one of the hashes, if necessary. * This simplifies gas cost calculations, but the problem described in the `Fees` section remains. * Contracts can hash their messages before passing them to the `MessageBus` and achieve nearly the same outcome if they want to. -2. Ten only pushes to L2. Messages on L1 are provided signed by the enclave through an RPC and the MessageBus contract verifies that they have been signed by a correct enclave-owned key. +2. TEN only pushes to L2. Messages on L1 are provided signed by the enclave through an RPC and the MessageBus contract verifies that they have been signed by a correct enclave-owned key. * This disabled the option to read messages and ordering becomes problematic. * The API is different between layers, which might end up being a bad UX. ### Fees -When publishing a message on the Ten L2, storing the message will have a direct cost to the `Sequencer` who is publishing the Rollup in the form of gas. In order to channel this cost to the user who is publishing the message we would need some configurable properties. +When publishing a message on the TEN L2, storing the message will have a direct cost to the `Sequencer` who is publishing the Rollup in the form of gas. In order to channel this cost to the user who is publishing the message we would need some configurable properties. -**Assumption: Ten DAO** will vote and set the following properties: +**Assumption: TEN DAO** will vote and set the following properties: * `fixedMessageStoringCost` - this is the gas cost for storing the fixed-size properties of the message * `dynamicCostPerByte` - this is the gas cost per byte for storing the dinamically sized data - `bytes payload`, `bytes topic` -> **_NOTE:_** This whole section might change based on the outcome of the Ten fees & rewards design. It only outlines a potential solution. +> **_NOTE:_** This whole section might change based on the outcome of the TEN fees & rewards design. It only outlines a potential solution. -The wormhole implementation requires that a fee is paid for each published message. This is something we should implement exactly as is to prevent people from spamming huge messages on L2 for a little gas cost that results in Ten having to pay for them being submitted to the L1! +The wormhole implementation requires that a fee is paid for each published message. This is something we should implement exactly as is to prevent people from spamming huge messages on L2 for a little gas cost that results in TEN having to pay for them being submitted to the L1! -The problem we will experience is that the native currency on Ten L2 will be different from the native currency on L1 - ETH. This means `ETH : TEN` pair volatility might result in losing money on gas costs. +The problem we will experience is that the native currency on TEN L2 will be different from the native currency on L1 - ETH. This means `ETH : TEN` pair volatility might result in losing money on gas costs. I see a couple of possible solutions to this: 1. Collect the fees in `WETH` when calling `publishMessage`. @@ -234,7 +234,7 @@ An additional insurance fee might be required. It is described in [Security](#Me ### Security -The security of the `MessageBus` is maintained by the `ManagementContract` and the enclave. When the `MessageBus` is secure, then all the downstream apps are secure too. **The maximum achievable security depends on the type of finality the Ten L2 has.** +The security of the `MessageBus` is maintained by the `ManagementContract` and the enclave. When the `MessageBus` is secure, then all the downstream apps are secure too. **The maximum achievable security depends on the type of finality the TEN L2 has.** * For probabilistic finality - We can be fully secure as L1 block reorgs will reorganize us too. * Fast & hard finality - Block reorgs can lead to instances of the enclave having delivered a message that got thrown away, even when accounting for confirmations. @@ -360,5 +360,5 @@ The security of the `MessageBus` guarantees that downstream dApps using it are a ## Decentralization -The `MessageBus` and `Bridge` contracts sit on-chain and inherit the least common denominator properties of both Ten and Eth. If Ten is decentralized then the Bridge and MessageBus will be too. +The `MessageBus` and `Bridge` contracts sit on-chain and inherit the least common denominator properties of both TEN and Eth. If TEN is decentralized then the Bridge and MessageBus will be too. diff --git a/design/finality_protocol/Soft_finality_guarantee.md b/design/finality_protocol/Soft_finality_guarantee.md index fe580895ef..542a915a0f 100644 --- a/design/finality_protocol/Soft_finality_guarantee.md +++ b/design/finality_protocol/Soft_finality_guarantee.md @@ -12,10 +12,10 @@ Note: See bridge and finality designs for more details ## Problem and Requirements The central sequencer is mainly responsible for the ordering (sequencing) of the L2 transactions. -The ordering of the L1 transactions like the deposits into the Ten bridge, is decided by the Ethereum staking nodes, +The ordering of the L1 transactions like the deposits into the TEN bridge, is decided by the Ethereum staking nodes, governed by the PoS Consensus. -Given that deposits affect the balances of accounts, which can be used in Ten transactions, there is a dependence +Given that deposits affect the balances of accounts, which can be used in TEN transactions, there is a dependence between the ordering of the L1 messages and the result of executing L2 transactions. In the "fast finality" design, the "soft finality" of an L2 transaction is defined as the moment when the sequencer produces @@ -42,9 +42,9 @@ factors unlikely to happen unless there is a re-org attack. Messages from the L1 are processed as they are found in the L1 blocks, and synthetic transactions are generated based on them. These synthetic transactions are implicitly included in the light batches. -A "synthetic transaction" is a transaction generated by the Ten protocol from some external data, with the intent of -bringing that data on the Ten chain, since these transactions will be addressed to a "system contract". -Every Ten node, given the same input data, will generate the same synthetic transactions, and thus correctly verify +A "synthetic transaction" is a transaction generated by the TEN protocol from some external data, with the intent of +bringing that data on the TEN chain, since these transactions will be addressed to a "system contract". +Every TEN node, given the same input data, will generate the same synthetic transactions, and thus correctly verify the state root of each rollup. @@ -68,7 +68,7 @@ an attacker must wait for x blocks until the deposit executes on Ten, and then p Note that with PoS, if the delay is 64 blocks (2 epochs), then re-org is mostly a theoretical possibility, because in practice it is prohibitively expensive for anyone. -The subtlety of this approach is that it can transform Ten into a side-chain even though we roll up to Ethereum. +The subtlety of this approach is that it can transform TEN into a side-chain even though we roll up to Ethereum. This depends on the definition of an L2, which is a moving target. If the consensus is that an L2 needs a re-org resistant bridge, then this option will break it. diff --git a/design/finality_protocol/fast_finality.md b/design/finality_protocol/fast_finality.md index cd5b620e5e..cabeb00789 100644 --- a/design/finality_protocol/fast_finality.md +++ b/design/finality_protocol/fast_finality.md @@ -14,7 +14,7 @@ described in the [Bootstrapping Strategy design doc](./sequencer_bootstrapping_s * Enclaves can be hacked; a signature from an attested enclave cannot be taken as an absolute proof that an attacker does not have control over the enclave's execution -* The market does not sufficiently trust the Ten foundation to allow it to run the sequencer unchecked; we +* The market does not sufficiently trust the TEN foundation to allow it to run the sequencer unchecked; we therefore need some validation of its execution to provide assurance * The adoption of the sequencer model may be long-lived, and must therefore be fully production ready * The enclave has a start-up delay that exceeds the production time for batches (see below) @@ -59,7 +59,7 @@ described in the [Bootstrapping Strategy design doc](./sequencer_bootstrapping_s * Censorship resistance * If censorship-resistance is achieved through an L1 inbox mechanism, it is acceptable for the costs of the - associated L1 transactions (which will be greater than the Ten costs) to fall on the transaction submitter + associated L1 transactions (which will be greater than the TEN costs) to fall on the transaction submitter * Resilience * During failover, upgrade or planned maintenance of the sequencer, it is acceptable to break the one-second soft-finality guarantee, and drop transactions that have not been soft-finalised (see e.g. @@ -267,7 +267,7 @@ identify value-extraction opportunities. #### Do nothing In this approach, we rely on trust in the sequencer and the fact that value-extraction opportunities are reduced in -Ten due to its data-visibility rules. +TEN due to its data-visibility rules. #### Disable `eth_call` on sequencer enclaves diff --git a/design/finality_protocol/sequencer_bootstrapping_strategy.md b/design/finality_protocol/sequencer_bootstrapping_strategy.md index 74763326eb..7bbade2c93 100644 --- a/design/finality_protocol/sequencer_bootstrapping_strategy.md +++ b/design/finality_protocol/sequencer_bootstrapping_strategy.md @@ -6,20 +6,20 @@ As we are getting closer to production and have already designed implemented the The POBI protocol described in the whitepaper assumes a network with significant traction. -To get there, we estimate Ten will need at least one year, most likely more. +To get there, we estimate TEN will need at least one year, most likely more. Other things we have to take into consideration during bootstrapping is code maturity and security. In the industry, this is called a period where the "training wheels" are on. The other major L2 networks (Arbitrum and Optimism), opted for a pragmatic approach where they started out with a centralised sequencer. -We propose that Ten starts out similarly to the L2s. Centralised block production and decentralised validation. +We propose that TEN starts out similarly to the L2s. Centralised block production and decentralised validation. ## Single block producer This is in essence a very simplified "POBI" with a single aggregator (SA). -The SA is operated by the Ten Foundation, and is configured as a variable in the Ten Management Contract (MC) on Ethereum. +The SA is operated by the TEN Foundation, and is configured as a variable in the TEN Management Contract (MC) on Ethereum. Only the foundation has the power to set the designated SA. Note that this means that the "Consensus problem" becomes relatively simple in this first stage. @@ -107,7 +107,7 @@ In the first stage we'll rely on trust that the SA will operate correctly, mostl ### Requirements of a Protocol for fast finality -If we wouldn't have to worry about scalability, or if Ten functioned like transparent chains, then the SA could just emit events and receipts when it processes a tx, +If we wouldn't have to worry about scalability, or if TEN functioned like transparent chains, then the SA could just emit events and receipts when it processes a tx, and send them to a caching layer to be consumed by clients. Also, the state could be cached, so that "eth_call" requests could be handled from the caching layer. diff --git a/design/gateway/gateway_caching.md b/design/gateway/gateway_caching.md index 8eb3c70bb7..d5c3612ecf 100644 --- a/design/gateway/gateway_caching.md +++ b/design/gateway/gateway_caching.md @@ -1,8 +1,8 @@ -# Ten Gateway Caching Design +# TEN Gateway Caching Design ## 1. Why cache requests on Gateway? -Currently, all `eth_` requests that hit the gateway are forwarded to the Ten Nodes and are executed by the Ten enclave. +Currently, all `eth_` requests that hit the gateway are forwarded to the TEN Nodes and are executed by the TEN enclave. This is not ideal since there is only one Sequencer and it can be overloaded with requests and there can be timeouts or errors in the sequencer. diff --git a/design/security/Escape_hatch.md b/design/security/Escape_hatch.md index 4ecfaf75ec..466c424e42 100644 --- a/design/security/Escape_hatch.md +++ b/design/security/Escape_hatch.md @@ -1,7 +1,7 @@ ## Handling catastrophic events -Ten is facing more risk than a transparent network during unforeseen situations. +TEN is facing more risk than a transparent network during unforeseen situations. With traditional software, if a bug prevents all nodes from starting up, the developers can quickly fix the bug, release the version, and the network will proceed. This works because there are no visibility restrictions on the existing data. As long as the data is not corrupted beyond recovery, there is always a path forward. @@ -45,7 +45,7 @@ Ideally, a mechanism that relies on verifying digital signatures and Merkle Tree To reduce the scope of abuse, we propose that, during phase 1, only the sequencer can enter "Safe mode". -Upgrade proof signed by an ad-hoc "upgrade oracle" composed of most of the Ten node operators at the time +Upgrade proof signed by an ad-hoc "upgrade oracle" composed of most of the TEN node operators at the time of each version. The public keys of all these nodes will be included in the image. diff --git a/design/security/Source_of_truth.md b/design/security/Source_of_truth.md index 929e2a396f..7bc10f82dd 100644 --- a/design/security/Source_of_truth.md +++ b/design/security/Source_of_truth.md @@ -1,6 +1,6 @@ -# An objective source of truth for the Ten Enclave +# An objective source of truth for the TEN Enclave -A TEE-based network like Ten needs a reliable and objective source of truth to function correctly and protect the +A TEE-based network like TEN needs a reliable and objective source of truth to function correctly and protect the data privacy in the face of complex attacks by the node operator. ## Problems @@ -12,13 +12,13 @@ The lack of reliable source-of-truths mechanisms can lead to the following types Note: we will analyse each of these attacks below. -Ten is an Ethereum Layer 2, so it is natural to consider the Ethereum chain as the source of truth. +TEN is an Ethereum Layer 2, so it is natural to consider the Ethereum chain as the source of truth. The transition to proof-of-stake is making the problem even more difficult because one of the tradeoffs made when designing that protocol was to weaken the objectivity assumption to "Weak subjectivity". ### Revelation period -Ten has a built-in mechanism to reveal encryption keys for transactions after a configured amount of time. +TEN has a built-in mechanism to reveal encryption keys for transactions after a configured amount of time. The difficulty is how to measure time reliably inside an enclave. When Ethereum was based on proof-of-work, we could rely on the number of Ethereum blocks that have been consumed by the enclave @@ -33,13 +33,13 @@ challenging. The threat is that a hacker learns about an SGX vulnerability after there is already a patch available and wants to use compromised hardware on a snapshot of the network state to decrypt the historical data. -Note: Ten reveals data anyway, so the impact of such an attack in real life would be reduced, but we need to make our best effort to keep +Note: TEN reveals data anyway, so the impact of such an attack in real life would be reduced, but we need to make our best effort to keep the guarantee of the revelation period. -### Transparent Ten Upgrades +### Transparent TEN Upgrades -A TEE-based system like Ten must be upgradeable. +A TEE-based system like TEN must be upgradeable. During an upgrade, the new software version must be able to pick up from the old version, which means that the previous version must share some of its secrets with the new version. @@ -100,7 +100,7 @@ an upgrade in a dark room without anyone knowing. In phase 2, we can decentralise by creating a more complex incentive-driven lifecycle. 1. A developer proposes a new version by publishing a GitHub tag (hash) and the Attestation of an enclave built from that code, - together with a stake. Initially, the developer will likely be the Ten Foundation. + together with a stake. Initially, the developer will likely be the TEN Foundation. 2. Anyone posting a stake can make a challenge to this version. The challenge period is predetermined. @@ -129,7 +129,7 @@ This mechanism has several advantages: #### Transparent upgrades conclusion -Ten will implement the transparent, smart-contract-driven upgrade process, starting out with the centralised approach and then decentralising in the next phase. +TEN will implement the transparent, smart-contract-driven upgrade process, starting out with the centralised approach and then decentralising in the next phase. The design needs two key ingredients: 1. The enclave must understand the outputs of the smart contract. @@ -291,8 +291,8 @@ Note: These are still unreviewed draft proposals at this stage. #### Solution 1 - Batched publishing to Bitcoin -The naive solution described above is inefficient because every single Ten node has to periodically publish a transaction to Bitcoin. -One immediate improvement is for the Ten nodes to join forces and generate shared randomness (`SR`) during a cycle, +The naive solution described above is inefficient because every single TEN node has to periodically publish a transaction to Bitcoin. +One immediate improvement is for the TEN nodes to join forces and generate shared randomness (`SR`) during a cycle, and then someone publishes this `SR` to Bitcoin. This achieves the same result, as it convinces every enclave that participated in this cycle that its timestamp is valid. @@ -322,10 +322,10 @@ Q1: why would someone aggregate these nonces? Find incentives Q2: what exactly is published, by whom, why? Incentives -#### Solution 2 - Nonce validated by the Ten network +#### Solution 2 - Nonce validated by the TEN network -Another potential solution is to rely on the Ten network itself to validate the randomness. -This is more tricky to achieve because of the subjectivity of the Ten network participants. +Another potential solution is to rely on the TEN network itself to validate the randomness. +This is more tricky to achieve because of the subjectivity of the TEN network participants. ##### Protocol @@ -333,7 +333,7 @@ Draft: Every N Ethereum epoch started, the enclave will generate a payload containing a newly generated nonce, the last checkpoint hash, and the current Attestation. -The host is responsible for collecting signatures from the other Ten nodes over this payload. +The host is responsible for collecting signatures from the other TEN nodes over this payload. The rule is that an enclave receiving a request from another enclave will sign over it only if the latest checkpoint coincides, and the Attestation is valid. @@ -350,7 +350,7 @@ sign over a payload that points to an unknown or a past epoch. After a couple of The most difficult problem with this approach is establishing the validity of the confirmation signatures themselves. In the hypothetical "long-range" scenario where the attacker spins up an enclave on a snapshot of a database from 6 months ago, -the Ten nodes that this enclave considers active might no longer be. +the TEN nodes that this enclave considers active might no longer be. If these nodes are decommissioned, then they will not respond, so the attack will fail quickly. The problem comes when we assume the attacker now controls these servers. To perform the attack, they must all be in synch and respond to each other. diff --git a/design/security/Upgrade_Design.md b/design/security/Upgrade_Design.md index e051d61384..ccfd7f480b 100644 --- a/design/security/Upgrade_Design.md +++ b/design/security/Upgrade_Design.md @@ -1,7 +1,7 @@ -# Ten Upgrades +# TEN Upgrades This design covers the operational aspects of upgrading Ten. -The mechanism by which the community validates an upgrade is covered in the [Ten source of truth](./Source_of_truth.md) document. +The mechanism by which the community validates an upgrade is covered in the [TEN source of truth](./Source_of_truth.md) document. We'll start by identifying the types of scenarios that will require a software upgrade, and next, we'll propose the procedures and the technical changes required to achieve them. @@ -10,16 +10,16 @@ Note: This document is written with the single aggregator model, but it also app ## Prerequisites -Upgradeability is a very complex topic. We'll start by listing the concerns specific to Ten and by creating +Upgradeability is a very complex topic. We'll start by listing the concerns specific to TEN and by creating some useful classifications to be able to reason about the problems. -### Ten secrets +### TEN secrets -There are two main secrets on an Ten node : +There are two main secrets on an TEN node : 1. The master seed, aka "the shared secret", is the basis of all communication between enclaves, users and enclaves, and data availability on Ethereum. 2. The key for connecting to the local database, which lives in its enclave. - - Note: Ten uses EdgelessDB, a modified MySQL running inside an enclave. The connection to the database is made using a key generated during the setup phase of the enclave. The EdgelessDB enclave ensures that only the owner of that key can read data. + - Note: TEN uses EdgelessDB, a modified MySQL running inside an enclave. The connection to the database is made using a key generated during the setup phase of the enclave. The EdgelessDB enclave ensures that only the owner of that key can read data. Access to these secrets will allow attackers to read private user data. Both secrets are sealed locally with a key derived from the current measurement of the enclave. @@ -36,7 +36,7 @@ can connect to the same database if it passes the attestation requirements it ha - The privacy of the ledger data is guaranteed by the security of the local secrets. - The main reason for a "privacy" upgrade is the discovery of a vulnerability that can leak data. - Most upgrades will hopefully be for mundane reasons such as new features or general improvements. -- Ten is an L2 with a governance mechanism on the Ethereum Management Contract (MC). The decisions made by +- TEN is an L2 with a governance mechanism on the Ethereum Management Contract (MC). The decisions made by the governance contract must be understood and enforced by the enclave. See more details in the "Source_of_truth.md" document. @@ -99,7 +99,7 @@ This version can be installed by a node operator at any time and is optional. ### 3. Privacy related upgrades -This type of upgrade specific to Ten (or other privacy networks) is necessary to remove a side channel or another avenue where data can be leaked. +This type of upgrade specific to TEN (or other privacy networks) is necessary to remove a side channel or another avenue where data can be leaked. This is not a "consensus upgrade" in the traditional sense, but it has to be treated equally because if there is a single node operator with a vulnerable version on the network, then privacy is considered compromised. @@ -110,7 +110,7 @@ After the rollout of such an upgrade, it is mandatory to change the secrets. Upgrading the SGX firmware or completely changing hardware falls under the same category. -## Ten architecture +## TEN architecture In this section, we'll look at the architecture and analyse how upgrading different components fits into the above categories. @@ -122,7 +122,7 @@ Any change to this codebase must go through the attestation whitelisting process Note that some changes can be "local only", such as a release containing only a performance improvement. -Note that Ten will allow multiple approved versions in the period between two block heights. +Note that TEN will allow multiple approved versions in the period between two block heights. ### Host @@ -131,8 +131,8 @@ Some upgrades could also be consensus upgrades, for example, on a change of prot ### The Wallet extension -End users install this component that communicates with Ten nodes via RPC. -For a good UX, Ten nodes must be backwards compatible and support even older versions of the Wallet extension. +End users install this component that communicates with TEN nodes via RPC. +For a good UX, TEN nodes must be backwards compatible and support even older versions of the Wallet extension. There must be warnings and mechanisms to help users upgrade to the latest version. @@ -247,7 +247,7 @@ this luxury. Without a mechanism put in place in the initial release, the enclave cannot be upgraded at all because any other version will not be able to read the data. -Upgradability in phase 1 is only a concern for the Ten enclave, as upgrading the "Host" component can be designed afterwards. +Upgradability in phase 1 is only a concern for the TEN enclave, as upgrading the "Host" component can be designed afterwards. ### High-level tasks @@ -350,7 +350,7 @@ further reduce the chance of the same error happening everywhere. ### Joining the network -There will be mechanisms in place to prevent users from starting a non-current version of an Ten Node. +There will be mechanisms in place to prevent users from starting a non-current version of an TEN Node. These mechanisms are necessary to prevent exploiting of already fixed privacy vulnerabilities. This means that a node joining the network must do so with the latest version which must contain all the compatibility modes diff --git a/design/security/high_availability.md b/design/security/high_availability.md index 030b3ad366..9dfc2e789a 100644 --- a/design/security/high_availability.md +++ b/design/security/high_availability.md @@ -1,6 +1,6 @@ # High availability -The Ten Sequencer must have HA capabilities. The reasoning is covered in the "Fast finality" design docs. +The TEN Sequencer must have HA capabilities. The reasoning is covered in the "Fast finality" design docs. The requirement is that the service must continue even if the enclave of the sequencer crashes and is corrupted. @@ -12,14 +12,14 @@ between them to ensure that service goes on uninterrupted. ## MEV Protection -The Sequencer is the only Ten node capable of producing Light Batches, and thus the only node that can in theory +The Sequencer is the only TEN node capable of producing Light Batches, and thus the only node that can in theory attempt to extract value via MEV. If the operator has multiple enclaves available operating in "Sequencer" mode it can both provide an uninterrupted service and extract some value at the same time. Introducing startup delays does not help too much in this case, because the operator could hold key transactions for longer. -An alternative solution is to introduce transparency into the lifecycle events of the sequencer enclaves, such that the Ten network +An alternative solution is to introduce transparency into the lifecycle events of the sequencer enclaves, such that the TEN network can assess the likelihood of bad behaviour. Lifecycle events: @@ -60,7 +60,7 @@ Todo - each event points to the previous event to prevent the operator from tran ? Periodically (todo - how often? Every batch?), the sequencer host will request a `RestartEvent` from each of the whitelisted enclaves it controls. -It will add these events to the `ProtocolPayload`, and broadcast them to the Ten network together with the Batch. +It will add these events to the `ProtocolPayload`, and broadcast them to the TEN network together with the Batch. Upon restart, each enclave records the required data as a variable, and will return that variable in the right struct each time it is being asked. This proof cannot be forged without a significant bug in the software or impersonation of the enclave. diff --git a/design/security/randomness_design.md b/design/security/randomness_design.md index e9c5effc49..73cb3daa4b 100644 --- a/design/security/randomness_design.md +++ b/design/security/randomness_design.md @@ -1,8 +1,8 @@ -# Randomness in Ten design +# Randomness in TEN design ## Scope -The purpose of this document is to describe how randomness is generated and exposed to Ten smart contracts. +The purpose of this document is to describe how randomness is generated and exposed to TEN smart contracts. ## Overview diff --git a/design/ux/Events_design.md b/design/ux/Events_design.md index 444ef55464..7f8b749997 100644 --- a/design/ux/Events_design.md +++ b/design/ux/Events_design.md @@ -1,8 +1,8 @@ -# Events in Ten - Design document +# Events in TEN - Design document ## Scope -This is a design proposal for how to handle events in Ten. +This is a design proposal for how to handle events in TEN. It covers two aspects: @@ -77,10 +77,10 @@ be used for subscribing. As the ultimate flexible mechanism we propose a programmatic way to determine whether a requester is allowed to view an event. If the implicit rules are not satisfactory, the smart contract developer can define a view function called -``eventVisibility``, which will be called by the Ten VM behind the scenes. +``eventVisibility``, which will be called by the TEN VM behind the scenes. ```solidity - // If declared in a smart contract, this function will be called by the Ten VM to determine whether the requester + // If declared in a smart contract, this function will be called by the TEN VM to determine whether the requester // address is allowed to view the event. function eventVisibility(address requester, bytes32[] memory topics, bytes32[] memory data) external view returns (bool){ // based on the data from the event, passed in as an array of topic and data (which is the internal VM representation) @@ -91,7 +91,7 @@ If the implicit rules are not satisfactory, the smart contract developer can def } ``` -To determine the visibility of an event, the Ten VM will do the following: +To determine the visibility of an event, the TEN VM will do the following: 1. call the `eventVisibility` with the event being requested and the requester. 2. If the function exists and returns 'true', then return the event. If it returns `false`, then the event is invisible. @@ -109,12 +109,12 @@ public, privacy-leaking `Transfer` event. This rule adds another dimension to the reasoning process, because there is an implicit user to whom the event is relevant. It also reduces flexibility in sending lifecycle events to administrators. -## Ten events implementation +## TEN events implementation Our goal is to implement the visibility rules described above without modifying the Ethereum events API. We will look first at the changes to the enclave, then those to the host, and finally those to the RPC client. -### Ten enclave +### TEN enclave #### Creating and deleting logs subscriptions @@ -160,7 +160,7 @@ the log filter and the address the logs are for. It then crawls the chain, extra and are relevant based on the address provided. It returns these logs encrypted with the viewing key corresponding to the address provided. -### Ten host +### TEN host #### Logs subscriptions @@ -185,7 +185,7 @@ on to the corresponding Geth `rpc.Subscription`. For log snapshot requests, it is again forwarded blindly to the enclave, with the host unable to learn anything about the request or response. -### Ten encrypted RPC client +### TEN encrypted RPC client Due to their sensitive nature, logs requests and log subscriptions must pass through the encrypted RPC client. @@ -193,7 +193,7 @@ Due to their sensitive nature, logs requests and log subscriptions must pass thr The encrypted RPC client only handles logs subscriptions via the `eth_subscribe` and `eth_unsubscribe` APIs (see [here](https://ethereum.org/en/developers/tutorials/using-websockets/#eth-subscribe)). A consequence of this is that -events are only available in Ten over a websocket connection. +events are only available in TEN over a websocket connection. In response to the incoming `eth_subscribe` request, the client creates a `logs` subscription to the host by making a `rpc.Client.Subscribe` call via the embedded Geth client. It passes as a parameter a `LogSubscription` object encrypted diff --git a/design/ux/Ten_Gateway.md b/design/ux/Ten_Gateway.md index 5a2a4b1c00..88e1b80475 100644 --- a/design/ux/Ten_Gateway.md +++ b/design/ux/Ten_Gateway.md @@ -1,6 +1,6 @@ -# The Ten Gateway - Design +# The TEN Gateway - Design -The scope of this document is to design a hosted [Wallet Extension](wallet_extension.md) called the "Ten Gateway" (TG). +The scope of this document is to design a hosted [Wallet Extension](wallet_extension.md) called the "TEN Gateway" (TG). The TG will be a superset of the WE functionality, so this document will only cover the additions. @@ -12,12 +12,12 @@ The current WE is designed to be used by a single user holding multiple addresse The TG must support mutiple users, each with multiple addresses. It can be seen as offering a WE per user. -The Ten node has no concept of "User". It only authenticates based on the "blockchain address". +The TEN node has no concept of "User". It only authenticates based on the "blockchain address". It expects to be supplied with a signed viewing key per address, so that it can respond encrypted with that VK. *Note that multiple addresses can share a VK.* -The role of the current WE is to manage a list of authenticated viewing keys (AVK), which it uses behind the scenes to communicate with an Ten node. +The role of the current WE is to manage a list of authenticated viewing keys (AVK), which it uses behind the scenes to communicate with an TEN node. The AVKs are stored on the local computer in a file. An AVK is a text containing the hash of the public viewing key signed with the "spending key" that controls a blockchain address. @@ -28,7 +28,7 @@ The diagram below depicts the setup once the TG is implemented. @startuml 'https://plantuml.com/deployment-diagram -cloud "Ten Nodes" +cloud "TEN Nodes" actor Alice component "Alice's Computer"{ @@ -39,29 +39,29 @@ component "Alice's Computer"{ Alice --> "Alice's MetaMask" "Alice's MetaMask" --> "Alice's Wallet Extension" "Alice's Wallet Extension" <-> "Alice's Viewing Keys" -"Alice's Wallet Extension" ----> "Ten Nodes" : Encrypted RPC +"Alice's Wallet Extension" ----> "TEN Nodes" : Encrypted RPC actor Bob component "Bob's Computer"{ agent "Bob's MetaMask" } component "Confidential Web Service"{ - node "Ten Gateway" + node "TEN Gateway" database "TG Viewing Keys" } -"TG Viewing Keys" <-> "Ten Gateway" +"TG Viewing Keys" <-> "TEN Gateway" Bob --> "Bob's MetaMask" -"Bob's MetaMask" ---> "Ten Gateway" : HTTPS -"Ten Gateway" ----> "Ten Nodes" : Encrypted RPC +"Bob's MetaMask" ---> "TEN Gateway" : HTTPS +"TEN Gateway" ----> "TEN Nodes" : Encrypted RPC actor Charlie component "Charlie's Computer"{ agent "Charlie's MetaMask" } -node "Ten Gateway" +node "TEN Gateway" Charlie --> "Charlie's MetaMask" -"Charlie's MetaMask" ---> "Ten Gateway" : HTTPS +"Charlie's MetaMask" ---> "TEN Gateway" : HTTPS @enduml ``` @@ -121,13 +121,13 @@ group Third click Alice -> MM : Confirm signature end -Alice -> TG: All further Ten interactions will be to\nhttps://gateway.ten.org/v1?token=$EncryptionToken +Alice -> TG: All further TEN interactions will be to\nhttps://gateway.ten.org/v1?token=$EncryptionToken @enduml ``` The onboarding should be done in 3 clicks. -1. The user goes to a website (like "ten.org"), where she clicks "Join Ten". This will add a network to their wallet. +1. The user goes to a website (like "ten.org"), where she clicks "Join TEN". This will add a network to their wallet. 2. User connects the wallet to the page. 3. In the wallet popup, the user has to sign over EIP-712 formatted message. @@ -160,7 +160,7 @@ types: { ##### Click 1 1. Behind the scenes, a js functions calls "gateway.ten.org/v1/join" where it will generate a VK and send back the hash of the Public key. This is the "encryption token" 2. After receiving the Encryption token, the js function will add a new network to the wallet. -The RPC URL of the new Ten network will include the encryption token: "https://gateway.ten.org/v1?token=$EncryptionToken". +The RPC URL of the new TEN network will include the encryption token: "https://gateway.ten.org/v1?token=$EncryptionToken". Notice that the encryption token has to be included as a query parameter because it must be encrypted by https, as it is secret. ##### Click 2 @@ -180,7 +180,7 @@ Note: Alternative UXes that achieve the same goal are ok. ### Register subsequent addresses -User Alice is onboarded already and has the Ten network configured in her wallet with an encryption token. +User Alice is onboarded already and has the TEN network configured in her wallet with an encryption token. She has to go to the same landing page as above and connect her wallet, instead of hitting "Join". When connecting, she can choose a second account. diff --git a/design/ux/block_explorer.md b/design/ux/block_explorer.md index 5a779bc183..6b06b973ae 100644 --- a/design/ux/block_explorer.md +++ b/design/ux/block_explorer.md @@ -2,7 +2,7 @@ ## Scope -The design for the Ten block explorers, tools to allow users to make sense of the contents of the Ten chain. +The design for the TEN block explorers, tools to allow users to make sense of the contents of the TEN chain. There will be two tools - a public block explorer that only displays public information, and a private block explorer that also displays private information belonging to that user. @@ -75,8 +75,8 @@ BlockScout is an open-source block explorer, used by Secret Network among others In theory, this would give us a block explorer "for free". In practice, we'd need to customise BlockScout to a large extent, even for the public block explorer, for two reasons: -* It cannot handle the fact that some information about the Ten chain is returned in an encrypted form. For - example, if vanilla BlockScout is connected to an Ten host, it correctly displays the number of Ten blocks, +* It cannot handle the fact that some information about the TEN chain is returned in an encrypted form. For + example, if vanilla BlockScout is connected to an TEN host, it correctly displays the number of TEN blocks, but it considers every block to have zero transactions, because it chokes on the encrypted transaction contents being returned * Every advanced block explorer has some customised handling of standard contracts. For example, for ERC-20, it will @@ -92,4 +92,4 @@ of viewing keys. Forking BlockScout would require us to develop skills we don't have currently (e.g. it is written in Elixir). Once BlockScout was forked, we'd have to maintain the fork. Blockscout is currently c. 270k lines of code, 20% larger -than the Ten codebase as of this writing. +than the TEN codebase as of this writing. diff --git a/design/ux/user_data_incentives.md b/design/ux/user_data_incentives.md index d9495edc7a..bd5cd117a2 100644 --- a/design/ux/user_data_incentives.md +++ b/design/ux/user_data_incentives.md @@ -1,4 +1,4 @@ -# User interaction with Ten +# User interaction with TEN In a typical transparent blockchain, there are service providers like "Infura" who act as the interface to the blockchain from the point of view of most users. @@ -29,7 +29,7 @@ Also, the service provider will not gain any insights from this service since al The usual rescue in the crypto space is to employ incentives. -Ten is a decentralised network of nodes with different roles who already have their own incentives (Aggregators and Verifiers). +TEN is a decentralised network of nodes with different roles who already have their own incentives (Aggregators and Verifiers). The ideal scenario is to have a large and diverse community of verifiers node to make sure that the network functions correctly. @@ -62,7 +62,7 @@ Given that everyone is now expecting this to be a free service, this is unlikely The network (or protocol) charges fees from user when submitting transactions. This is something that users expect to pay. -The Ten protocol is designed in such a way that it decouples the income from the costs by maintaining a buffer. +The TEN protocol is designed in such a way that it decouples the income from the costs by maintaining a buffer. We can use this designed mechanism to pay for node usage as well along with the L1 gas fees and the general incentives to follow the protocol. diff --git a/design/ux/wallet_extension.md b/design/ux/wallet_extension.md index 7116f7074a..a926468cc2 100644 --- a/design/ux/wallet_extension.md +++ b/design/ux/wallet_extension.md @@ -3,7 +3,7 @@ ## Scope The design for the wallet extension, a component that is responsible for handling RPC requests from traditional -Ethereum wallets (e.g. MetaMask, hardware wallets), tooling (e.g. Remix) and webapps to the Ten host. +Ethereum wallets (e.g. MetaMask, hardware wallets), tooling (e.g. Remix) and webapps to the TEN host. ## Requirements @@ -44,7 +44,7 @@ Ethereum wallets (e.g. MetaMask, hardware wallets), tooling (e.g. Remix) and web ## Design -The wallet extension is a local server application that maintains an RPC connection to one or more Ten hosts. It +The wallet extension is a local server application that maintains an RPC connection to one or more TEN hosts. It serves two endpoints: * An endpoint for managing viewing keys @@ -68,9 +68,9 @@ event, the following steps are taken: * The wallet extension stores the private key locally, tagged with the address it is associated with * The end user signs a payload containing the public key and some metadata using an account key in their wallet (e.g. MetaMask), proving that the viewing key is "authorised" by the account in question -* The wallet extension sends the public key and signature to the Ten enclave via the Ten host over RPC -* The Ten enclave checks the signature -* The Ten enclave stores the public key locally, tagged with the address it is associated with +* The wallet extension sends the public key and signature to the TEN enclave via the TEN host over RPC +* The TEN enclave checks the signature +* The TEN enclave stores the public key locally, tagged with the address it is associated with Whenever an enclave needs to send sensitive information to the end user (e.g. a transaction result or account balance), it encrypts the sensitive information with the viewing key associated with the account. This ensures that the sensitive @@ -88,14 +88,14 @@ viewing keys for the configured host (as identified by the URL and port) are loa The wallet extension serves a standard implementation of the Ethereum JSON-RPC specification, except in the following respects: -* The wallet extension encrypts any request containing sensitive information with the Ten enclave public key before - forwarding it to the Ten host +* The wallet extension encrypts any request containing sensitive information with the TEN enclave public key before + forwarding it to the TEN host * The enclave encrypts any response containing sensitive information with the viewing public key for the address *associated* with that request (see below) * The wallet extension decrypts any encrypted responses with the viewing private key before forwarding them on to the user -This ensures that the encryption and decryption involved in the Ten protocol is transparent to the end user, and +This ensures that the encryption and decryption involved in the TEN protocol is transparent to the end user, and that we are not relying on decryption capabilities being available in the wallet. How do we determine which address is associated with a given request? @@ -157,7 +157,7 @@ Snaps are an experimental MetaMask capability. Snaps have several downsides: -* Snaps need to be installed per-page, requiring a code change in every webapp to prompt the user to install the Ten +* Snaps need to be installed per-page, requiring a code change in every webapp to prompt the user to install the TEN snap * Snaps are only compatible with MetaMask * Snaps are marked as experimental and require users to switch from MetaMask to the experimental MetaMask Flask diff --git a/developer_onboarding_guide.md b/developer_onboarding_guide.md index 731ab660bd..31fef5065e 100644 --- a/developer_onboarding_guide.md +++ b/developer_onboarding_guide.md @@ -50,6 +50,6 @@ To do so, follow these steps: - Click on the `Run local tests` [link](https://github.com/ten-protocol/ten-test/actions/workflows/run_local_tests.yml) - Click `Run workflow`, enter the name of your branch, and then click `Run workflow` -## Ten smart contracts +## TEN smart contracts -Documentation for Ten smart contracts is available [here](https://github.com/ten-protocol/go-ten/blob/main/contracts/README.md). \ No newline at end of file +Documentation for TEN smart contracts is available [here](https://github.com/ten-protocol/go-ten/blob/main/contracts/README.md). \ No newline at end of file diff --git a/dockerfiles/README.md b/dockerfiles/README.md index 15714d604b..fbe81dbbf4 100644 --- a/dockerfiles/README.md +++ b/dockerfiles/README.md @@ -1,6 +1,6 @@ -# Ten enclave service Docker image +# TEN enclave service Docker image -The Docker image defined by `enclave.Dockerfile` creates a Docker image for an Ten enclave service running in SGX. +The Docker image defined by `enclave.Dockerfile` creates a Docker image for an TEN enclave service running in SGX. To build the image, run: docker build -t enclave -f dockerfiles/enclave.Dockerfile . @@ -12,12 +12,12 @@ local machine, and `YYY` is the address of the node that this enclave service is docker run -p XXX:11000/tcp enclave --hostID YYY --address :11000 -By default, the image runs the Ten enclave service in SGX simulation mode. To run the enclave service in +By default, the image runs the TEN enclave service in SGX simulation mode. To run the enclave service in non-simulation mode instead, run: docker run -e OE_SIMULATION=0 --privileged -v /dev/sgx:/dev/sgx -p XXX:11000/tcp enclave --hostID YYY --address :11000 --willAttest=true -Stop and remove all Ten docker containers: +Stop and remove all TEN docker containers: docker rm $(docker stop $(docker ps -a -q --filter ancestor=enclave --format="{{.ID}}")) diff --git a/go/common/gethencoding/geth_encoding.go b/go/common/gethencoding/geth_encoding.go index 33f819591a..41520020f8 100644 --- a/go/common/gethencoding/geth_encoding.go +++ b/go/common/gethencoding/geth_encoding.go @@ -345,7 +345,7 @@ func (enc *gethEncodingServiceImpl) CreateEthBlockFromBatch(ctx context.Context, return (*types.Block)(unsafe.Pointer(&lb)), nil } -// ExtractPrivateTransactionsQuery is designed to support a wide range of custom Ten queries. +// ExtractPrivateTransactionsQuery is designed to support a wide range of custom TEN queries. // The first parameter here is the method name, which is used to determine the query type. // The second parameter is the query parameters. func ExtractPrivateTransactionsQuery(queryParams any) (*common.ListPrivateTransactionsQueryParams, error) { diff --git a/go/common/headers.go b/go/common/headers.go index bea9c8ed91..8bdf733b4b 100644 --- a/go/common/headers.go +++ b/go/common/headers.go @@ -37,7 +37,7 @@ type BatchHeader struct { BaseFee *big.Int `json:"baseFee"` Coinbase common.Address `json:"coinbase"` - // The custom Ten fields. + // The custom TEN fields. L1Proof L1BlockHash `json:"l1Proof"` // the L1 block used by the enclave to generate the current batch Signature []byte `json:"signature"` CrossChainMessages []MessageBus.StructsCrossChainMessage `json:"crossChainMessages"` diff --git a/go/config/enclave_config.go b/go/config/enclave_config.go index fdeec56d00..1b7e331c39 100644 --- a/go/config/enclave_config.go +++ b/go/config/enclave_config.go @@ -54,7 +54,7 @@ type EnclaveConfig struct { MessageBusAddress gethcommon.Address // P2P address for validators to connect to the sequencer for live batch data SequencerP2PAddress string - // A json string that specifies the prefunded addresses at the genesis of the Ten network + // A json string that specifies the prefunded addresses at the genesis of the TEN network TenGenesis string // Whether debug calls are available DebugNamespaceEnabled bool diff --git a/go/enclave/evm/README.md b/go/enclave/evm/README.md index 1c9fabe500..0089cdf119 100644 --- a/go/enclave/evm/README.md +++ b/go/enclave/evm/README.md @@ -1,4 +1,4 @@ -Ten executes EVM compatible transactions on top of a database that implements the Go-Ethereum interfaces. +TEN executes EVM compatible transactions on top of a database that implements the Go-Ethereum interfaces. The entry point is the evm_facade. diff --git a/go/enclave/l2chain/README.md b/go/enclave/l2chain/README.md index 2ea92b5492..404ba3b1fe 100644 --- a/go/enclave/l2chain/README.md +++ b/go/enclave/l2chain/README.md @@ -1,4 +1,4 @@ -This is where the bulk of the Ten specific logic is. +This is where the bulk of the TEN specific logic is. The entry point is the `L2Chain`. Ethereum Blocks and Rollups produced by peers are fed into this datastructure, and it decides which is the canonical chain, diff --git a/go/enclave/rpc/README.md b/go/enclave/rpc/README.md index 1b970bc7f6..b07cea232c 100644 --- a/go/enclave/rpc/README.md +++ b/go/enclave/rpc/README.md @@ -1,2 +1,2 @@ -All communication to and from Ten is encrypted. -This package handles the encryption logic between end users communicating via RPC with the Ten enclave. \ No newline at end of file +All communication to and from TEN is encrypted. +This package handles the encryption logic between end users communicating via RPC with the TEN enclave. \ No newline at end of file diff --git a/go/enclave/storage/enclavedb/README.md b/go/enclave/storage/enclavedb/README.md index f243e7a8e7..0d40f19f6a 100644 --- a/go/enclave/storage/enclavedb/README.md +++ b/go/enclave/storage/enclavedb/README.md @@ -5,8 +5,8 @@ Currently, it is at the first version which is a little rough. ### Historical reasoning for the current design: 1. Geth is implemented on top of levelDB, and so makes heavy use of the k/v mechanism. -2. Ten uses EdglessDb in production, and sqlite in testing. -3. Ten started out by implementing the k/v primitives on top of sql. +2. TEN uses EdglessDb in production, and sqlite in testing. +3. TEN started out by implementing the k/v primitives on top of sql. 4. Then we decided to use the SQL features to simplify some business logic, which required exposing the sql primitives. 5. Eventually, we ended up using SQL for everything, except the evm functionality. diff --git a/go/enclave/storage/init/edgelessdb/edgelessdb.go b/go/enclave/storage/init/edgelessdb/edgelessdb.go index d9bcab2e7f..5a324d492c 100644 --- a/go/enclave/storage/init/edgelessdb/edgelessdb.go +++ b/go/enclave/storage/init/edgelessdb/edgelessdb.go @@ -41,7 +41,7 @@ import ( ) /* - The Ten Enclave (TE) needs a way to persist data into a trusted database. Trusted not to reveal that data to anyone but that particular enclave. + The TEN Enclave (TE) needs a way to persist data into a trusted database. Trusted not to reveal that data to anyone but that particular enclave. To achieve this, the TE must first perform Remote Attestation (RA), which gives it confidence that it is connected to a trusted version of software running on trusted hardware. The result of this process is a Certificate which can be @@ -130,7 +130,7 @@ type Credentials struct { UserKeyPEM string // db user private key, generated in our enclave } -// Connector (re-)establishes a connection to the Edgeless DB for the Ten enclave +// Connector (re-)establishes a connection to the Edgeless DB for the TEN enclave func Connector(edbCfg *Config, config config.EnclaveConfig, logger gethlog.Logger) (enclavedb.EnclaveDB, error) { // rather than fail immediately if EdgelessDB is not available yet we wait up for `edgelessDBStartTimeout` for it to be available err := waitForEdgelessDBToStart(edbCfg.Host, logger) @@ -228,8 +228,8 @@ func performHandshake(enclaveConfig config.EnclaveConfig, edbCfg *Config, logger // the RA will ensure that we are connecting to a database that will not leak any data. // The RA will return a Certificate which we'll use for the TLS mutual authentication when we connect to the database. // The trust path is as follows: - // 1. The Ten Enclave performs RA on the database enclave, and the RA object contains a certificate which only the database enclave controls. - // 2. Connecting to the database via mutually authenticated TLS using the above certificate, will give the Ten enclave confidence that it is only giving data away to some code and hardware it trusts. + // 1. The TEN Enclave performs RA on the database enclave, and the RA object contains a certificate which only the database enclave controls. + // 2. Connecting to the database via mutually authenticated TLS using the above certificate, will give the TEN enclave confidence that it is only giving data away to some code and hardware it trusts. edbPEM, err := performEDBRemoteAttestation(enclaveConfig, edbCfg.Host, defaultEDBConstraints, logger) if err != nil { return nil, err diff --git a/go/host/container/cli_flags.go b/go/host/container/cli_flags.go index cc01c4b7c6..c44c67b1ce 100644 --- a/go/host/container/cli_flags.go +++ b/go/host/container/cli_flags.go @@ -50,7 +50,7 @@ func getFlagUsageMap() map[string]string { clientRPCPortHTTPName: "The port on which to listen for client application RPC requests over HTTP", clientRPCPortWSName: "The port on which to listen for client application RPC requests over websockets", clientRPCHostName: "The host on which to handle client application RPC requests", - enclaveRPCAddressesName: "The comma-separated addresses to use to connect to the Ten enclaves", + enclaveRPCAddressesName: "The comma-separated addresses to use to connect to the TEN enclaves", p2pBindAddressName: "The address where the p2p server is bound to. Defaults to 0.0.0.0:10000", p2pPublicAddressName: "The P2P address where the other servers should connect to. Defaults to 127.0.0.1:10000", l1WebsocketURLName: "The websocket RPC address the host can use for L1 requests", diff --git a/go/host/rpc/clientapi/client_api_ten.go b/go/host/rpc/clientapi/client_api_ten.go index ce664b6665..542d44de41 100644 --- a/go/host/rpc/clientapi/client_api_ten.go +++ b/go/host/rpc/clientapi/client_api_ten.go @@ -19,12 +19,12 @@ func NewTenAPI(host host.Host) *TenAPI { } } -// Health returns the health status of Ten host + enclave + db +// Health returns the health status of TEN host + enclave + db func (api *TenAPI) Health(ctx context.Context) (*host.HealthCheck, error) { return api.host.HealthCheck(ctx) } -// Config returns the config status of Ten host + enclave + db +// Config returns the config status of TEN host + enclave + db func (api *TenAPI) Config() (*ChecksumFormattedTenNetworkConfig, error) { config, err := api.host.TenConfig() if err != nil { diff --git a/go/node/README.md b/go/node/README.md index 1acf839a88..beea54cab8 100644 --- a/go/node/README.md +++ b/go/node/README.md @@ -1,3 +1,3 @@ # Node package -This package is responsible for orchestrating the start of various components that make up the ten node. +This package is responsible for orchestrating the start of various components that make up the TEN node. diff --git a/go/obsclient/README.md b/go/obsclient/README.md index 7ab9b3a2fb..58bc4f3e9a 100644 --- a/go/obsclient/README.md +++ b/go/obsclient/README.md @@ -1,12 +1,12 @@ This package is analogous to the ethclient package in go-ethereum. -It provides a higher level, standard way to interact with an Ten network programmatically. +It provides a higher level, standard way to interact with an TEN network programmatically. -It aims to provide all the same methods that the geth ethclient provides for compatibility/familiarity, as well as ten-specific methods. +It aims to provide all the same methods that the geth ethclient provides for compatibility/familiarity, as well as TEN-specific methods. There are two clients, `ObsClient` and `AuthObsClient` -`ObsClient` just requires a Client and provides access to general Ten functionality that doesn't require viewing keys. +`ObsClient` just requires a Client and provides access to general TEN functionality that doesn't require viewing keys. `AuthObsClient` requires a EncRPCClient, which is an RPC client with an account and a signed Viewing Key for authentication. -It provides full Ten functionality, authenticating with the node and encrypting/decrypting sensitive requests. \ No newline at end of file +It provides full TEN functionality, authenticating with the node and encrypting/decrypting sensitive requests. \ No newline at end of file diff --git a/go/rpc/README.md b/go/rpc/README.md index 98e975e405..a228498a64 100644 --- a/go/rpc/README.md +++ b/go/rpc/README.md @@ -1,8 +1,8 @@ -This package contains library code to allow client applications to connect to Ten nodes via RPC. +This package contains library code to allow client applications to connect to TEN nodes via RPC. ### Viewing keys -Viewing keys are generated inside the wallet extension (or other users of the ten rpc client), and then signed by the wallet (e.g. MetaMask) +Viewing keys are generated inside the wallet extension (or other users of the TEN rpc client), and then signed by the wallet (e.g. MetaMask) to which the keys relate. The keys are then are sent to the enclave via RPC and processed by: - checking the validity of the signature over the viewing key diff --git a/go/rpc/client.go b/go/rpc/client.go index 6a87987b4d..b53740ecab 100644 --- a/go/rpc/client.go +++ b/go/rpc/client.go @@ -53,7 +53,7 @@ const ( GetPersonalTransactions = "scan_getPersonalTransactions" ) -// Client is used by client applications to interact with the Ten node +// Client is used by client applications to interact with the TEN node type Client interface { // Call executes the named method via RPC. Call(result interface{}, method string, args ...interface{}) error diff --git a/go/rpc/encrypted_client.go b/go/rpc/encrypted_client.go index be553e6aff..abc4030fb5 100644 --- a/go/rpc/encrypted_client.go +++ b/go/rpc/encrypted_client.go @@ -233,7 +233,7 @@ func (c *EncRPCClient) decryptResponse(encryptedBytes []byte) ([]byte, error) { return decryptedResult, nil } -// creates a subscription to the Ten node, but decrypts the messages from that channel and forwards them to the `ch` +// creates a subscription to the TEN node, but decrypts the messages from that channel and forwards them to the `ch` func (c *EncRPCClient) logSubscription(ctx context.Context, namespace string, ch interface{}, args ...any) (*gethrpc.ClientSubscription, error) { outboundChannel, ok := ch.(chan types.Log) if !ok { diff --git a/integration/README.md b/integration/README.md index 3d3fc67b46..77a74a3d83 100644 --- a/integration/README.md +++ b/integration/README.md @@ -1,4 +1,4 @@ -These packages contain code related to the simulation and testing an end-to-end Ten network. +These packages contain code related to the simulation and testing an end-to-end TEN network. To include the Docker tests when running the tests, build the Docker images using the instructions in the `dockerfiles/` folder, then run the tests with the `docker` tag (e.g. `go test -v -tags docker ./...`). diff --git a/integration/networktest/env/network_setup.go b/integration/networktest/env/network_setup.go index a1a0a89f5b..0e79cdfaa8 100644 --- a/integration/networktest/env/network_setup.go +++ b/integration/networktest/env/network_setup.go @@ -87,7 +87,7 @@ func (t *testnetEnv) Prepare() (networktest.NetworkConnector, func(), error) { go func() { err := t.tenGatewayContainer.Stop() if err != nil { - fmt.Println("failed to stop ten gateway", err.Error()) + fmt.Println("failed to stop TEN gateway", err.Error()) } }() } @@ -115,10 +115,10 @@ func (t *testnetEnv) startTenGateway() { } tenGWContainer := walletextension.NewContainerFromConfig(cfg, t.logger) - fmt.Println("Starting Ten Gateway, HTTP Port:", _gwHTTPPort, "WS Port:", _gwWSPort) + fmt.Println("Starting TEN Gateway, HTTP Port:", _gwHTTPPort, "WS Port:", _gwWSPort) err := tenGWContainer.Start() if err != nil { - t.logger.Error("failed to start ten gateway", "err", err) + t.logger.Error("failed to start TEN gateway", "err", err) panic(err) } t.tenGatewayContainer = tenGWContainer diff --git a/integration/noderunner/noderunner_test.go b/integration/noderunner/noderunner_test.go index 1fe18cb1c2..30b14c856c 100644 --- a/integration/noderunner/noderunner_test.go +++ b/integration/noderunner/noderunner_test.go @@ -23,7 +23,7 @@ const ( _startPort = integration.StartPortNodeRunnerTest ) -// A smoke test to check that we can stand up a standalone Ten host and enclave. +// A smoke test to check that we can stand up a standalone TEN host and enclave. func TestCanStartStandaloneTenHostAndEnclave(t *testing.T) { testlog.Setup(&testlog.Cfg{ LogDir: _testLogs, diff --git a/integration/simulation/devnetwork/dev_network.go b/integration/simulation/devnetwork/dev_network.go index 562235314b..e1c15e9f13 100644 --- a/integration/simulation/devnetwork/dev_network.go +++ b/integration/simulation/devnetwork/dev_network.go @@ -36,7 +36,7 @@ const ( var _defaultFaucetAmount = big.NewInt(750_000_000_000_000) -// InMemDevNetwork is a local dev network (L1 and L2) - the Ten nodes are in-memory in a single go process, the L1 nodes are a docker geth network +// InMemDevNetwork is a local dev network (L1 and L2) - the TEN nodes are in-memory in a single go process, the L1 nodes are a docker geth network // // It can play the role of node operators and network admins to reproduce complex scenarios around nodes joining/leaving/failing. // @@ -50,9 +50,9 @@ type InMemDevNetwork struct { l1Network L1Network - // When Ten network has been initialised on the L1 network, this will be populated + // When TEN network has been initialised on the L1 network, this will be populated // - if reconnecting to an existing network it needs to be populated when initialising this object - // - if it is nil when `Start()` is called then Ten contracts will be deployed on the L1 + // - if it is nil when `Start()` is called then TEN contracts will be deployed on the L1 l1SetupData *params.L1TenData tenConfig *TenConfig @@ -66,14 +66,14 @@ type InMemDevNetwork struct { func (s *InMemDevNetwork) GetGatewayURL() (string, error) { if !s.tenConfig.TenGatewayEnabled { - return "", fmt.Errorf("ten gateway not enabled") + return "", fmt.Errorf("TEN gateway not enabled") } return fmt.Sprintf("http://localhost:%d", _gwHTTPPort), nil } func (s *InMemDevNetwork) GetGatewayWSURL() (string, error) { if !s.tenConfig.TenGatewayEnabled { - return "", fmt.Errorf("ten gateway not enabled") + return "", fmt.Errorf("TEN gateway not enabled") } return fmt.Sprintf("ws://localhost:%d", _gwWSPort), nil } @@ -148,10 +148,10 @@ func (s *InMemDevNetwork) Start() { s.l1Network.Prepare() if s.l1SetupData == nil { // this is a new network, deploy the contracts to the L1 - fmt.Println("Deploying Ten contracts to L1") + fmt.Println("Deploying TEN contracts to L1") s.deployTenNetworkContracts() } - fmt.Println("Starting Ten nodes") + fmt.Println("Starting TEN nodes") s.startNodes() // sleep to allow the nodes to start @@ -214,10 +214,10 @@ func (s *InMemDevNetwork) startTenGateway() { } tenGWContainer := walletextension.NewContainerFromConfig(cfg, s.logger) go func() { - fmt.Println("Starting Ten Gateway, HTTP Port:", _gwHTTPPort, "WS Port:", _gwWSPort) + fmt.Println("Starting TEN Gateway, HTTP Port:", _gwHTTPPort, "WS Port:", _gwWSPort) err := tenGWContainer.Start() if err != nil { - s.logger.Error("failed to start ten gateway", "err", err) + s.logger.Error("failed to start TEN gateway", "err", err) panic(err) } s.tenGatewayContainer = tenGWContainer @@ -244,7 +244,7 @@ func (s *InMemDevNetwork) CleanUp() { go func() { err := s.tenGatewayContainer.Stop() if err != nil { - fmt.Println("failed to stop ten gateway", err.Error()) + fmt.Println("failed to stop TEN gateway", err.Error()) } }() } diff --git a/integration/simulation/network/geth_network.go b/integration/simulation/network/geth_network.go index b1564b9068..7c1391a78b 100644 --- a/integration/simulation/network/geth_network.go +++ b/integration/simulation/network/geth_network.go @@ -40,7 +40,7 @@ func (n *networkInMemGeth) Create(params *params.SimParams, _ *stats.Stats) (*RP params.ERC20ContractLib = erc20contractlib.NewERC20ContractLib(¶ms.L1TenData.MgmtContractAddress, ¶ms.L1TenData.ObxErc20Address, ¶ms.L1TenData.EthErc20Address) - // Start the ten nodes and return the handles + // Start the TEN nodes and return the handles n.l2Clients = startInMemoryTenNodes(params, n.eth2Network.GenesisBytes(), n.gethClients) tenClients := make([]*obsclient.ObsClient, params.NumberOfNodes) @@ -58,7 +58,7 @@ func (n *networkInMemGeth) Create(params *params.SimParams, _ *stats.Stats) (*RP } func (n *networkInMemGeth) TearDown() { - // Stop the Ten nodes first + // Stop the TEN nodes first StopTenNodes(n.l2Clients) // Stop geth last diff --git a/integration/simulation/network/inmemory.go b/integration/simulation/network/inmemory.go index 79b162c19e..59897ce573 100644 --- a/integration/simulation/network/inmemory.go +++ b/integration/simulation/network/inmemory.go @@ -87,7 +87,7 @@ func (n *basicNetworkOfInMemoryNodes) Create(params *params.SimParams, stats *st // Here we first start the mock layer 1 nodes, with a pause between them of a fraction of a block duration. // The reason is to make sure that they catch up correctly. // Then we pause for a while, to give the L1 network enough time to create a number of blocks, which will have to be ingested by the en nodes - // Then, we begin the starting sequence of the Ten nodes, again with a delay between them, to test that they are able to cach up correctly. + // Then, we begin the starting sequence of the TEN nodes, again with a delay between them, to test that they are able to cach up correctly. // Note: Other simulations might test variations of this pattern. for _, m := range n.ethNodes { t := m diff --git a/integration/simulation/network/network.go b/integration/simulation/network/network.go index 15bd804b9e..7b1c3d2183 100644 --- a/integration/simulation/network/network.go +++ b/integration/simulation/network/network.go @@ -15,13 +15,13 @@ import ( "github.com/ten-protocol/go-ten/integration/simulation/stats" ) -// Network is responsible with knowing how to manage the lifecycle of networks of Ethereum or Ten nodes. +// Network is responsible with knowing how to manage the lifecycle of networks of Ethereum or TEN nodes. // These networks can be composed of in-memory go-routines or of fully fledged existing nodes like Ropsten. // Implementation notes: // - This is a work in progress, so there is a lot of code duplication in the implementations // - Once we implement a few more versions: for example using Geth, we'll revisit and create better abstractions. type Network interface { - // Create - returns the started Ethereum nodes and the started Ten node clients. + // Create - returns the started Ethereum nodes and the started TEN node clients. // Responsible with spinning up all resources required for the test // Return an error in case it cannot start for an expected reason, otherwise it panics. Create(params *params.SimParams, stats *stats.Stats) (*RPCHandles, error) @@ -32,9 +32,9 @@ type RPCHandles struct { // an eth client per eth node in the network EthClients []ethadapter.EthClient - // A Ten client per Ten node in the network. + // A TEN client per TEN node in the network. TenClients []*obsclient.ObsClient - // An RPC client per Ten node in the network (used for APIs that don't have methods on `ObsClient`. + // An RPC client per TEN node in the network (used for APIs that don't have methods on `ObsClient`. RPCClients []rpc.Client // an RPC client per node per wallet, with a viewing key set up (on the client and registered on its corresponding host enclave), diff --git a/integration/simulation/network/network_utils.go b/integration/simulation/network/network_utils.go index 5ee9a2204b..c32dfca906 100644 --- a/integration/simulation/network/network_utils.go +++ b/integration/simulation/network/network_utils.go @@ -102,7 +102,7 @@ func createInMemTenNode( enclaveLogger := testlog.Logger().New(log.NodeIDKey, id, log.CmpKey, log.EnclaveCmp) enclaveClients := []common.Enclave{enclave.NewEnclave(enclaveConfig, &genesis.TestnetGenesis, mgmtContractLib, enclaveLogger)} - // create an in memory Ten node + // create an in memory TEN node hostLogger := testlog.Logger().New(log.NodeIDKey, id, log.CmpKey, log.HostCmp) metricsService := metrics.New(hostConfig.MetricsEnabled, hostConfig.MetricsHTTPPort, hostLogger) l1Repo := l1.NewL1Repository(ethClient, ethereummock.MgmtContractAddresses, hostLogger) diff --git a/integration/simulation/network/obscuro_node_utils.go b/integration/simulation/network/obscuro_node_utils.go index 36f62690b4..94dc3f3f39 100644 --- a/integration/simulation/network/obscuro_node_utils.go +++ b/integration/simulation/network/obscuro_node_utils.go @@ -30,7 +30,7 @@ const ( ) func startInMemoryTenNodes(params *params.SimParams, genesisJSON []byte, l1Clients []ethadapter.EthClient) []rpc.Client { - // Create the in memory ten nodes, each connect each to a geth node + // Create the in memory TEN nodes, each connect each to a geth node tenNodes := make([]*hostcontainer.HostContainer, params.NumberOfNodes) tenHosts := make([]host.Host, params.NumberOfNodes) mockP2PNetw := p2p.NewMockP2PNetwork(params.AvgBlockDuration, params.AvgNetworkLatency, params.NodeWithInboundP2PDisabled) @@ -57,7 +57,7 @@ func startInMemoryTenNodes(params *params.SimParams, genesisJSON []byte, l1Clien tenHosts[i] = tenNodes[i].Host() } - // start each ten node + // start each TEN node for _, m := range tenNodes { t := m go func() { @@ -108,7 +108,7 @@ func CreateAuthClients(clients []rpc.Client, wal wallet.Wallet) []*obsclient.Aut return authClients } -// StopTenNodes stops the Ten nodes and their RPC clients. +// StopTenNodes stops the TEN nodes and their RPC clients. func StopTenNodes(clients []rpc.Client) { ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second) defer cancel() @@ -119,7 +119,7 @@ func StopTenNodes(clients []rpc.Client) { eg.Go(func() error { err := c.Call(nil, rpc.StopHost) if err != nil { - testlog.Logger().Error("Could not stop Ten node.", log.ErrKey, err) + testlog.Logger().Error("Could not stop TEN node.", log.ErrKey, err) return err } c.Stop() @@ -129,10 +129,10 @@ func StopTenNodes(clients []rpc.Client) { err := eg.Wait() if err != nil { - testlog.Logger().Error(fmt.Sprintf("Error waiting for the Ten nodes to stop - %s", err)) + testlog.Logger().Error(fmt.Sprintf("Error waiting for the TEN nodes to stop - %s", err)) } - testlog.Logger().Info("Ten nodes stopped") + testlog.Logger().Info("TEN nodes stopped") } // CheckHostRPCServersStopped checks whether the hosts' RPC server addresses have been freed up. @@ -157,10 +157,10 @@ func CheckHostRPCServersStopped(hostWSURLS []string) { err := eg.Wait() if err != nil { - panic(fmt.Sprintf("Timed out waiting for the Ten host RPC addresses to become available - %s", err)) + panic(fmt.Sprintf("Timed out waiting for the TEN host RPC addresses to become available - %s", err)) } - testlog.Logger().Info("Ten host RPC addresses freed") + testlog.Logger().Info("TEN host RPC addresses freed") } func isAddressAvailable(address string) bool { diff --git a/integration/simulation/network/socket.go b/integration/simulation/network/socket.go index 3f8ecf64b2..2154d71ed2 100644 --- a/integration/simulation/network/socket.go +++ b/integration/simulation/network/socket.go @@ -25,7 +25,7 @@ import ( "github.com/ten-protocol/go-ten/integration/simulation/stats" ) -// creates Ten nodes with their own enclave servers that communicate with peers via sockets, wires them up, and populates the network objects +// creates TEN nodes with their own enclave servers that communicate with peers via sockets, wires them up, and populates the network objects type networkOfSocketNodes struct { l2Clients []rpc.Client hostWebsocketURLs []string @@ -119,8 +119,8 @@ func (n *networkOfSocketNodes) Create(simParams *params.SimParams, _ *stats.Stat if errCheck != nil { testlog.Logger().Warn("no port found on error", log.ErrKey, err) } - fmt.Printf("unable to start Ten node: %s", err) - testlog.Logger().Error("unable to start Ten node ", log.ErrKey, err) + fmt.Printf("unable to start TEN node: %s", err) + testlog.Logger().Error("unable to start TEN node ", log.ErrKey, err) } } @@ -140,7 +140,7 @@ func (n *networkOfSocketNodes) Create(simParams *params.SimParams, _ *stats.Stat } func (n *networkOfSocketNodes) TearDown() { - // Stop the Ten nodes first (each host will attempt to shut down its enclave as part of shutdown). + // Stop the TEN nodes first (each host will attempt to shut down its enclave as part of shutdown). StopTenNodes(n.l2Clients) StopEth2Network(n.gethClients, n.eth2Network) CheckHostRPCServersStopped(n.hostWebsocketURLs) diff --git a/integration/simulation/p2p/in_mem_obscuro_client.go b/integration/simulation/p2p/in_mem_obscuro_client.go index 71d002a43b..0a53f3ffaa 100644 --- a/integration/simulation/p2p/in_mem_obscuro_client.go +++ b/integration/simulation/p2p/in_mem_obscuro_client.go @@ -118,7 +118,7 @@ func (c *inMemTenClient) Call(result interface{}, method string, args ...interfa } } -// CallContext not currently supported by in-memory ten client, the context will be ignored. +// CallContext not currently supported by in-memory TEN client, the context will be ignored. func (c *inMemTenClient) CallContext(_ context.Context, result interface{}, method string, args ...interface{}) error { return c.Call(result, method, args...) //nolint: contextcheck } diff --git a/integration/simulation/params/params.go b/integration/simulation/params/params.go index b20b9ab178..2782a81396 100644 --- a/integration/simulation/params/params.go +++ b/integration/simulation/params/params.go @@ -42,7 +42,7 @@ type SimParams struct { } type L1TenData struct { - // TenStartBlock is the L1 block hash where the Ten network activity begins (e.g. mgmt contract deployment) + // TenStartBlock is the L1 block hash where the TEN network activity begins (e.g. mgmt contract deployment) TenStartBlock common.Hash // MgmtContractAddr defines the management contract address MgmtContractAddress common.Address diff --git a/integration/simulation/simulation.go b/integration/simulation/simulation.go index 6bacf215c5..e947b732dd 100644 --- a/integration/simulation/simulation.go +++ b/integration/simulation/simulation.go @@ -62,7 +62,7 @@ func (s *Simulation) Start() { s.trackLogs() // Create log subscriptions, to validate that they're working correctly later. s.prefundTenAccounts() // Prefund every L2 wallet - s.deployTenERC20s() // Deploy the Ten HOC and POC ERC20 contracts + s.deployTenERC20s() // Deploy the TEN HOC and POC ERC20 contracts s.prefundL1Accounts() // Prefund every L1 wallet s.checkHealthStatus() // Checks the nodes health status @@ -109,14 +109,14 @@ func (s *Simulation) waitForTenGenesisOnL1() { continue } if _, ok := t.(*ethadapter.L1RollupTx); ok { - // exit at the first Ten rollup we see + // exit at the first TEN rollup we see return } } } } time.Sleep(s.Params.AvgBlockDuration) - testlog.Logger().Trace("Waiting for the Ten genesis rollup...") + testlog.Logger().Trace("Waiting for the TEN genesis rollup...") } } diff --git a/integration/simulation/validate_chain.go b/integration/simulation/validate_chain.go index a4ebc91c5f..9a2c22be8a 100644 --- a/integration/simulation/validate_chain.go +++ b/integration/simulation/validate_chain.go @@ -41,7 +41,7 @@ const ( // more than this, but this is a sanity check to ensure the simulation doesn't stop after a single transaction of each // type, for example. txThreshold = 5 - // The maximum number of blocks an Ten node can fall behind + // The maximum number of blocks an TEN node can fall behind maxBlockDelay = 5 // The leading zero bytes in a hash indicating that it is possibly an address, since it only has 20 bytes of data. zeroBytesHex = "000000000000000000000000" @@ -49,7 +49,7 @@ const ( // After a simulation has run, check as much as possible that the outputs of the simulation are expected. // For example, all injected transactions were processed correctly, the height of the rollup chain is a function of the total -// time of the simulation and the average block duration, that all Ten nodes are roughly in sync, etc +// time of the simulation and the average block duration, that all TEN nodes are roughly in sync, etc func checkNetworkValidity(t *testing.T, s *Simulation) { time.Sleep(2 * time.Second) checkTransactionsInjected(t, s) @@ -123,7 +123,7 @@ func checkTenBlockchainValidity(t *testing.T, s *Simulation, maxL1Height uint64) // This checks that all the nodes are in sync. When a node falls behind with processing blocks it might highlight a problem. // since there is one node that only listens to rollups it will be naturally behind. if max-min > max/3 { - t.Errorf("There is a problem with the Ten chain. Nodes fell out of sync. Max height: %d. Min height: %d -> %+v", max, min, heights) + t.Errorf("There is a problem with the TEN chain. Nodes fell out of sync. Max height: %d. Min height: %d -> %+v", max, min, heights) } } @@ -335,7 +335,7 @@ func checkBlockchainOfTenNode(t *testing.T, rpcHandles *network.RPCHandles, minT t.Errorf("Node %d: Could not retrieve L1 height. Cause: %s", nodeIdx, err) } if int(maxEthereumHeight)-int(l1Height) > maxBlockDelay { - t.Errorf("Node %d: Ten node fell behind by %d blocks.", nodeIdx, maxEthereumHeight-l1Height) + t.Errorf("Node %d: TEN node fell behind by %d blocks.", nodeIdx, maxEthereumHeight-l1Height) } // check that the height of the l2 chain is higher than a minimum expected value. diff --git a/integration/tengateway/tengateway_test.go b/integration/tengateway/tengateway_test.go index cfcf2a9af8..4edf962914 100644 --- a/integration/tengateway/tengateway_test.go +++ b/integration/tengateway/tengateway_test.go @@ -859,9 +859,9 @@ func transferRandomAddr(t *testing.T, client *ethclient.Client, w wallet.Wallet) return signedTx.Hash() } -// Creates a single-node Ten network for testing. +// Creates a single-node TEN network for testing. func createTenNetwork(t *testing.T, startPort int) { - // Create the Ten network. + // Create the TEN network. numberOfNodes := 1 wallets := params.NewSimWallets(1, numberOfNodes, integration.EthereumChainID, integration.TenChainID) simParams := params.SimParams{ @@ -878,7 +878,7 @@ func createTenNetwork(t *testing.T, startPort int) { t.Cleanup(tenNetwork.TearDown) _, err := tenNetwork.Create(&simParams, nil) if err != nil { - panic(fmt.Sprintf("failed to create test Ten network. Cause: %s", err)) + panic(fmt.Sprintf("failed to create test TEN network. Cause: %s", err)) } } diff --git a/integration/tenscan/tenscan_test.go b/integration/tenscan/tenscan_test.go index a76a9f1eff..dd8fc17184 100644 --- a/integration/tenscan/tenscan_test.go +++ b/integration/tenscan/tenscan_test.go @@ -290,9 +290,9 @@ func waitServerIsReady(serverAddr string) error { return fmt.Errorf("timed out before server was ready") } -// Creates a single-node Ten network for testing. +// Creates a single-node TEN network for testing. func createTenNetwork(t *testing.T, startPort int) { - // Create the Ten network. + // Create the TEN network. wallets := params.NewSimWallets(1, 1, integration.EthereumChainID, integration.TenChainID) simParams := params.SimParams{ NumberOfNodes: 1, @@ -308,7 +308,7 @@ func createTenNetwork(t *testing.T, startPort int) { t.Cleanup(tenNetwork.TearDown) _, err := tenNetwork.Create(&simParams, nil) if err != nil { - panic(fmt.Sprintf("failed to create test Ten network. Cause: %s", err)) + panic(fmt.Sprintf("failed to create test TEN network. Cause: %s", err)) } } diff --git a/lib/gethfork/README.MD b/lib/gethfork/README.MD index 3c4193ff5a..c47598981d 100644 --- a/lib/gethfork/README.MD +++ b/lib/gethfork/README.MD @@ -2,7 +2,7 @@ This package contains a fork of the rpc stack from go-ethereum. We need to change it, to add a custom authentication mechanism. -The RPC URL to the Ten Gateway contains a "token" URL parameter kept secret by every user, which we use for authentication. +The RPC URL to the TEN Gateway contains a "token" URL parameter kept secret by every user, which we use for authentication. 1. Create an http service: `extract_params_handler.go` which extracts it and adds it to the Context 2. From the Context, it can be read by the http rpc handler diff --git a/lib/gethfork/log/format.go b/lib/gethfork/log/format.go index 4c91b1ccdb..b4d30aec96 100644 --- a/lib/gethfork/log/format.go +++ b/lib/gethfork/log/format.go @@ -164,7 +164,7 @@ func FormatSlogValue(v slog.Value, tmp []byte) (result []byte) { return appendU256(tmp, v) case error: return appendEscapeString(tmp, v.Error()) - // case TerminalStringer: // Ten - commented out because + // case TerminalStringer: // TEN - commented out because // return appendEscapeString(tmp, v.TerminalString()) case fmt.Stringer: return appendEscapeString(tmp, v.String()) diff --git a/planning/Testnet release plan.md b/planning/Testnet release plan.md index 40fedda06e..4757abe874 100644 --- a/planning/Testnet release plan.md +++ b/planning/Testnet release plan.md @@ -24,7 +24,7 @@ Note that there is no protocol work listed here. These are the tasks that are or d) Try outside of Azure? 2. Design and implement reveleation period 3. Finalise cryptography - a) key derivation (both the ten network key, and the symmetric rollup encryption keys) + a) key derivation (both the TEN network key, and the symmetric rollup encryption keys) b) Calculate hashes on startup c) Check that the rollup producer is attested d) Add entropy to txs diff --git a/planning/testnet-kpis.md b/planning/testnet-kpis.md index 5bdabc7a97..03a23e2da5 100644 --- a/planning/testnet-kpis.md +++ b/planning/testnet-kpis.md @@ -1,8 +1,8 @@ # Measuring Testnet Success -The launch of a testnet in Web3 is a significant milestone for all projects. It demonstrates the capability of the solution, whether the project is likely to meet the promises shared with investors and with the community and it signifies a confident step towards mainnet. The final iterations of a testnet should very closely emulate mainnet and give assurances to users, developers and investors that the final product will be of a high quality with a high chance of success. As a result, the impression left by testnet is crucial to the expected success of a project and how it is perceived. The primary contributors of success for Ten testnet are whether it is attractive, it is being used and whether or not users have a positive experience with it. Making the degree of success quantifiable means defining mesaurable success criteria and collecting data to know whether those criteria are being met. +The launch of a testnet in Web3 is a significant milestone for all projects. It demonstrates the capability of the solution, whether the project is likely to meet the promises shared with investors and with the community and it signifies a confident step towards mainnet. The final iterations of a testnet should very closely emulate mainnet and give assurances to users, developers and investors that the final product will be of a high quality with a high chance of success. As a result, the impression left by testnet is crucial to the expected success of a project and how it is perceived. The primary contributors of success for TEN testnet are whether it is attractive, it is being used and whether or not users have a positive experience with it. Making the degree of success quantifiable means defining mesaurable success criteria and collecting data to know whether those criteria are being met. ## Testnet Success Criteria -Determining success for testnet will be a data-driven exercise, this being the best way to make measurable and repeatable observations. These observations can subsequently feed into decision-making with outcomes again being measured and compared. Included in the measurements will be criteria which, on the face of it, do not provide value however they have gained traction in the Web3 communicty as success indicators by which projects are judged. We need commentators to be able to compare Ten to other projects using like-for-like data points which the Web3 community are comfortable with even if they offer little value, or can even be misleading. For example, total number of transactions in a given period of time is a data point commonly used to compare projects yet it can be easily gamed. +Determining success for testnet will be a data-driven exercise, this being the best way to make measurable and repeatable observations. These observations can subsequently feed into decision-making with outcomes again being measured and compared. Included in the measurements will be criteria which, on the face of it, do not provide value however they have gained traction in the Web3 communicty as success indicators by which projects are judged. We need commentators to be able to compare TEN to other projects using like-for-like data points which the Web3 community are comfortable with even if they offer little value, or can even be misleading. For example, total number of transactions in a given period of time is a data point commonly used to compare projects yet it can be easily gamed. The testnet success criteria have been expressed below in the form of Key Performance Indicators with the rationale for their inclusion, the data source, the actual metric and the target value. ## Testnet KPIs @@ -11,8 +11,8 @@ Key performance indicators (KPIs) will be used to determine the amount of Testne ### Selected KPIs for Users | KPI NAME | RATIONALE | SOURCE | METRIC | TARGET | |--|--|--|--|--| -| Testnet uptime | Captures how robust and ready for mainnet Ten is | DataDog avg:system.uptime{*} | Average Testnet uptime over the last 4 weeks|99.9%| -| Number of wallets connected to Ten Gateway| Good proxy for the number of active users. Straightforward to capture.| Datadog? |Number of daily connections|500| +| Testnet uptime | Captures how robust and ready for mainnet TEN is | DataDog avg:system.uptime{*} | Average Testnet uptime over the last 4 weeks|99.9%| +| Number of wallets connected to TEN Gateway| Good proxy for the number of active users. Straightforward to capture.| Datadog? |Number of daily connections|500| | Number of transactions| Typical gauge of the amount of activity on testnet (even though it can be gamed).| Datadog? |Number of daily transactions|2000| | Number of RPC requests| Alternative gauge of the amount of activity on testnet. Can also show where RPC performance degrades.| Datadog? |Number of daily RPC requests|2000| @@ -29,17 +29,17 @@ These KPIs were considered and discounted for now. - Wallet extension downloads - Good proxy for the number of active users. - Straightforward to capture. - - Discounted because Ten Gateway is the recommended wallet connection method. + - Discounted because TEN Gateway is the recommended wallet connection method. - Ported Solidity dApps– original vs fork - - One of Ten’s key promises is that existing Solidity dApps will just work on Ten. This KPI helps track whether Ten is fulfilling this promise. The reason for differentiating between original fork e.g. Uniswap vs PancakeSwap is it further provides insight into whether original teams believe in Ten. + - One of Ten’s key promises is that existing Solidity dApps will just work on Ten. This KPI helps track whether TEN is fulfilling this promise. The reason for differentiating between original fork e.g. Uniswap vs PancakeSwap is it further provides insight into whether original teams believe in Ten. - Discounted because very difficult to determine of the dApps on Testnet which have been ported. - Number of nodes - Nodes secure the network and track general interest in Ten. This KPI also provides an input into the staking function and has an impact on tokenomics. - - Discounted for now because Ten Labs will run the nodes. When validator nodes can be run by others, this KPI will be introduced. + - Discounted for now because TEN Labs will run the nodes. When validator nodes can be run by others, this KPI will be introduced. - Faucet requests - Tracks the number of tokens being requested and whether users are coming back for more. Straightforward to capture. - Discounted because it can be gamed too easily leading to misleading results. - Number of organisations building on Testnet - - Funded organisations building on Ten vs individuals. Good indicator of the long-term health of dApps being built on Ten and expands on number of new dApps. + - Funded organisations building on TEN vs individuals. Good indicator of the long-term health of dApps being built on TEN and expands on number of new dApps. - Discounted because large effort required to determine who is building on Testnet. diff --git a/testnet/launcher/docker.go b/testnet/launcher/docker.go index 1954bfafa2..05eed725b6 100644 --- a/testnet/launcher/docker.go +++ b/testnet/launcher/docker.go @@ -73,14 +73,14 @@ func (t *Testnet) Start() error { err = sequencerNode.Start() if err != nil { - return fmt.Errorf("unable to start the Ten node - %w", err) + return fmt.Errorf("unable to start the TEN node - %w", err) } - fmt.Println("Ten node was successfully started...") + fmt.Println("TEN node was successfully started...") // wait until the node is healthy err = waitForHealthyNode(80) if err != nil { - return fmt.Errorf("sequencer Ten node not healthy - %w", err) + return fmt.Errorf("sequencer TEN node not healthy - %w", err) } validatorNodeConfig := node.NewNodeConfig( @@ -119,7 +119,7 @@ func (t *Testnet) Start() error { if err != nil { return fmt.Errorf("unable to start the obscuro node - %w", err) } - fmt.Println("Ten validator node was successfully started...") + fmt.Println("TEN validator node was successfully started...") // wait until the node it healthy err = waitForHealthyNode(13010) diff --git a/tools/bridge-frontend/README.md b/tools/bridge-frontend/README.md index 0bc7fa7cc4..0f6bd9f968 100644 --- a/tools/bridge-frontend/README.md +++ b/tools/bridge-frontend/README.md @@ -2,7 +2,7 @@ -The Ten Bridge is a decentralized bridge that allows users to move assets between the Ethereum network and the TEN network. The bridge is a critical component of the TEN ecosystem, enabling users to move assets between the two networks seamlessly. +The TEN Bridge is a decentralized bridge that allows users to move assets between the Ethereum network and the TEN network. The bridge is a critical component of the TEN ecosystem, enabling users to move assets between the two networks seamlessly. For more information on the TEN bridge, please refer to the [TEN Bridge Documentation](https://docs.ten.xyz/bridge). diff --git a/tools/bridge-frontend/pages/index.tsx b/tools/bridge-frontend/pages/index.tsx index c44af4c09e..fe814be009 100644 --- a/tools/bridge-frontend/pages/index.tsx +++ b/tools/bridge-frontend/pages/index.tsx @@ -1,8 +1,8 @@ import { Metadata } from "next"; export const metadata: Metadata = { - title: "Ten Bridge", - description: "Ten Bridge Dashboard", + title: "TEN Bridge", + description: "TEN Bridge Dashboard", }; export default function DashboardPage() { diff --git a/tools/faucet/README.md b/tools/faucet/README.md index 718a9aca5e..6ba678594b 100644 --- a/tools/faucet/README.md +++ b/tools/faucet/README.md @@ -1,7 +1,7 @@ -# Ten Faucet +# TEN Faucet -This tools contains a Faucet to allow allocation of ETH tokens within an Ten network. For more information -on Ten see the [Ten repo](https://github.com/ten-protocol/go-ten) and [documentation](https://docs.ten.xyz/). +This tools contains a Faucet to allow allocation of ETH tokens within an TEN network. For more information +on TEN see the [TEN repo](https://github.com/ten-protocol/go-ten) and [documentation](https://docs.ten.xyz/). ## Repository Structure The top level structure of the tool is as below; @@ -24,9 +24,9 @@ To run a local container and run the Faucet use the below; $ ./container_run.sh ``` -By default, when running locally the Faucet will connect to a local testnet started as described in the go-ten +By default, when running locally the Faucet will connect to a local testnet started as described in the go-TEN project repo [readme](https://github.com/ten-protocol/go-ten#building-and-running-a-local-testnet). It will connect -to the Ten node running within the local testnet on host `validator-host` and port `13010`. The Faucet opens +to the TEN node running within the local testnet on host `validator-host` and port `13010`. The Faucet opens on port `80` within the container, but maps port `8080` on the host machine to this. diff --git a/tools/gateway-js/gateway-lib/README.md b/tools/gateway-js/gateway-lib/README.md index 10bdce0ff5..d51883faef 100644 --- a/tools/gateway-js/gateway-lib/README.md +++ b/tools/gateway-js/gateway-lib/README.md @@ -1,6 +1,6 @@ -# Ten Gateway JS +# TEN Gateway JS -A JavaScript library for the gateway, providing streamlined access and functionalities for interacting with the Ten network. +A JavaScript library for the gateway, providing streamlined access and functionalities for interacting with the TEN network. ## Table of Contents @@ -13,7 +13,7 @@ A JavaScript library for the gateway, providing streamlined access and functiona ## Features -- Seamless connection to Ten Network. +- Seamless connection to TEN Network. - Easy-to-use methods for joining and authenticating. - External consumption support through CDN or NPM. diff --git a/tools/hardhatdeployer/README.md b/tools/hardhatdeployer/README.md index 1ab5a21cb6..e800b33816 100644 --- a/tools/hardhatdeployer/README.md +++ b/tools/hardhatdeployer/README.md @@ -1,6 +1,6 @@ # Contract deployer -Deploys contracts to both the ten network (L2) and eth network (L1) +Deploys contracts to both the TEN network (L2) and eth network (L1) ## Usage @@ -8,7 +8,7 @@ All commands are executed by running `contractdeployer/main/main()`. Contract is a string value to select the contract bytecode to deploy, currently ERC20, and MGMT are supported: - `ERC20`: a standard ERC20 contract -- `MGMT`: the Ten L1 management contract +- `MGMT`: the TEN L1 management contract * Example arguments to deploy an L2 contract: diff --git a/tools/tenscan/frontend/public/docs/terms.json b/tools/tenscan/frontend/public/docs/terms.json index 6becc3b6ed..02697959a9 100644 --- a/tools/tenscan/frontend/public/docs/terms.json +++ b/tools/tenscan/frontend/public/docs/terms.json @@ -5,7 +5,7 @@ { "heading": "1. GENERAL INFORMATION", "content": [ - "Obscuro Limited (“our,” “us,” “we” or “Obscuro Labs“), a private limited company incorporated and registered in England and Wales under company number 13873741 with a registered office at Ground Floor, Cromwell House, 15 Andover Road, Winchester, SO23 7BT, UK, welcomes you. These Terms of Service (\"Terms\") govern your access to and use of the Website, Ten Testnet services and software (collectively, the \"Services\"). By using our Services, you agree to these Terms.", + "Obscuro Limited (“our,” “us,” “we” or “Obscuro Labs“), a private limited company incorporated and registered in England and Wales under company number 13873741 with a registered office at Ground Floor, Cromwell House, 15 Andover Road, Winchester, SO23 7BT, UK, welcomes you. These Terms of Service (\"Terms\") govern your access to and use of the Website, TEN Testnet services and software (collectively, the \"Services\"). By using our Services, you agree to these Terms.", "These Terms set forth the legal terms and conditions governing your Testnet use. These Terms, along with any of our other policies and rules referenced herein, comprise the entire understanding between you and Obscuro Labs regarding the Services and supersede all other agreements, understandings, or representations with respect to such subject matter, either written or oral. If you do not agree to these Terms, do not use our Services.", "By using our Services, you confirm that you accept these Terms and that you agree to be bound by and comply with these Terms, and you represent and warrant that you have the willingness, right, authority, and capacity to enter into these Terms (on behalf of yourself or the entity that you represent). If you do not agree to all of these Terms in their entirety, you may not use the Services or any other related site in any manner.", "You must be 18 years of age or older to use the Services. By using the Services, you confirm, represent and warrant that you meet these requirements." @@ -97,7 +97,7 @@ "heading": "14. GENERAL TERMS", "content": [ "Information Only. You agree that the Services (or any information provided by or obtained from the Services) are for informational purposes only, are not intended to be relied upon for professional advice of any sort, and is not a substitute for information from experts or professionals in the applicable area. You should not take, or refrain from taking, any action or decision based on any information contained in the Services. If, and before you make any financial, legal, or other decisions involving the Services, you should seek independent professional advice from an individual who is licensed and qualified in the area for which such advice would be appropriate.", - "Open-Source: Ten is being developed on an open-source basis under the GNU Affero General Public License, Version 3.0, the terms of which are found here: https://www.gnu.org/licenses/agpl-3.0.html (the “AGPLv3 Licence“). By accessing, using, copying (or similar) the Services, you agree that the Services shall be governed by the AGPLv3 Licence (and the Terms herein). The Services are licensed under the AGPLv3 License and you undertake that you will not use the Services except in compliance with the AGPLv3 License and these Terms. You agree that any software developed using the Services, shall be made available for the public to use on an open source basis, on the AGPLv3 License terms.", + "Open-Source: TEN is being developed on an open-source basis under the GNU Affero General Public License, Version 3.0, the terms of which are found here: https://www.gnu.org/licenses/agpl-3.0.html (the “AGPLv3 Licence“). By accessing, using, copying (or similar) the Services, you agree that the Services shall be governed by the AGPLv3 Licence (and the Terms herein). The Services are licensed under the AGPLv3 License and you undertake that you will not use the Services except in compliance with the AGPLv3 License and these Terms. You agree that any software developed using the Services, shall be made available for the public to use on an open source basis, on the AGPLv3 License terms.", "Compliance with Law. You represent and warrant that you will comply with all laws that apply to you, your use of the Services, and your actions and omissions that relate to the Services. If your use of the Services is prohibited by applicable laws, then you aren’t authorised to use the Services. We will not be responsible for your using the Services (and developing and/or deploying any software) in a way that is a violation of any law. Without limiting the foregoing, you represent and warrant that you are not, and for the duration of the time you use the Services (to develop any software or similar) will not be (a) the subject of economic or trade sanctions administered or enforced by any governmental authority or otherwise designated on any list of prohibited or restricted parties (including but not limited to the United Nations Security Council, the European Union, His Majesty’s Treasury, and U.S. Department of Treasury), or (b) a citizen, resident, or organised in a jurisdiction or territory that is the subject of comprehensive country-wide, territory-wide, or regional economic sanctions by the United Nations, European Union, any EU country, UK Treasury, or the United States, including without limitation Cuba, the Crimea, Donetsk, and Luhansk regions of Ukraine, Iran, North Korea, Russia, Syria, Yemen and any other regions and/or countries sanctioned from time to time. If at any point the above is no longer true, you must immediately cease using the Services.", "Assumption of Risk. By using the Services, you (a) represent that you are sophisticated enough to understand the various inherent risks of using cryptographic and public blockchain-based systems, including but not limited to the Services and digital assets, and (b) acknowledge and accept all such risks, and agree that we make no representations or warranties (expressly or implicitly) regarding, and that you will not hold us liable for those risks, including but not limited to the risks described below, any or all of which could lead to losses and damages, including the total and irrevocable loss of your assets. These risks include, but are not limited to:", "", diff --git a/tools/tenscan/frontend/src/components/modules/personal/columns.tsx b/tools/tenscan/frontend/src/components/modules/personal/columns.tsx index 03fc288e3d..3c1faa6ac9 100644 --- a/tools/tenscan/frontend/src/components/modules/personal/columns.tsx +++ b/tools/tenscan/frontend/src/components/modules/personal/columns.tsx @@ -15,7 +15,7 @@ export const columns: ColumnDef[] = [ { accessorKey: "blockNumber", header: ({ column }) => ( - + ), cell: ({ row }) => { return ( @@ -32,7 +32,7 @@ export const columns: ColumnDef[] = [ { accessorKey: "blockHash", header: ({ column }) => ( - + ), cell: ({ row }) => { return ; diff --git a/tools/walletextension/README.md b/tools/walletextension/README.md index 1224fd6d99..1b46ca278b 100644 --- a/tools/walletextension/README.md +++ b/tools/walletextension/README.md @@ -1,5 +1,5 @@ -# Ten Gateway Documentation +# TEN Gateway Documentation For a comprehensive overview, refer to the [official documentation](https://docs.ten.xyz/docs/tools-infrastructure/hosted-gateway). @@ -44,7 +44,7 @@ Example: - **`--verbose`**: Flag to enable verbose logging of wallet extension traffic. Default: `false`. - **`--dbType`**: Define the database type (`sqlite` or `mariaDB`). Default: `sqlite`. - **`--dbConnectionURL`**: If `dbType` is set to `mariaDB`, this must be set. -- **`--tenChainID`**: ChainID of the Ten network that the gateway is communicating with. Default: `443`. +- **`--tenChainID`**: ChainID of the TEN network that the gateway is communicating with. Default: `443`. - **`--storeIncomingTxs`**: Flag to enable storing incoming transactions in the database for debugging purposes. Default: `true`. - **`--rateLimitUserComputeTime`**: Represents how much compute time a user is allowed to use within the `rateLimitWindow` time. Set to `0` to disable rate limiting. Default: `10s`. - **`--rateLimitWindow`**: Time window in which a user is allowed to use the defined compute time. Default: `1m`. @@ -64,7 +64,7 @@ The frontend will be accessible on `http://localhost:3000`. ## HTTP Endpoints -Ten Gateway exposes several HTTP endpoints for interaction: +TEN Gateway exposes several HTTP endpoints for interaction: - **`GET /v1/join`** Generates and returns a `userID`, which needs to be added as a query parameter `u` in your Metamask (or another provider) URL to identify you. diff --git a/tools/walletextension/frontend/public/docs/terms.json b/tools/walletextension/frontend/public/docs/terms.json index 6becc3b6ed..02697959a9 100644 --- a/tools/walletextension/frontend/public/docs/terms.json +++ b/tools/walletextension/frontend/public/docs/terms.json @@ -5,7 +5,7 @@ { "heading": "1. GENERAL INFORMATION", "content": [ - "Obscuro Limited (“our,” “us,” “we” or “Obscuro Labs“), a private limited company incorporated and registered in England and Wales under company number 13873741 with a registered office at Ground Floor, Cromwell House, 15 Andover Road, Winchester, SO23 7BT, UK, welcomes you. These Terms of Service (\"Terms\") govern your access to and use of the Website, Ten Testnet services and software (collectively, the \"Services\"). By using our Services, you agree to these Terms.", + "Obscuro Limited (“our,” “us,” “we” or “Obscuro Labs“), a private limited company incorporated and registered in England and Wales under company number 13873741 with a registered office at Ground Floor, Cromwell House, 15 Andover Road, Winchester, SO23 7BT, UK, welcomes you. These Terms of Service (\"Terms\") govern your access to and use of the Website, TEN Testnet services and software (collectively, the \"Services\"). By using our Services, you agree to these Terms.", "These Terms set forth the legal terms and conditions governing your Testnet use. These Terms, along with any of our other policies and rules referenced herein, comprise the entire understanding between you and Obscuro Labs regarding the Services and supersede all other agreements, understandings, or representations with respect to such subject matter, either written or oral. If you do not agree to these Terms, do not use our Services.", "By using our Services, you confirm that you accept these Terms and that you agree to be bound by and comply with these Terms, and you represent and warrant that you have the willingness, right, authority, and capacity to enter into these Terms (on behalf of yourself or the entity that you represent). If you do not agree to all of these Terms in their entirety, you may not use the Services or any other related site in any manner.", "You must be 18 years of age or older to use the Services. By using the Services, you confirm, represent and warrant that you meet these requirements." @@ -97,7 +97,7 @@ "heading": "14. GENERAL TERMS", "content": [ "Information Only. You agree that the Services (or any information provided by or obtained from the Services) are for informational purposes only, are not intended to be relied upon for professional advice of any sort, and is not a substitute for information from experts or professionals in the applicable area. You should not take, or refrain from taking, any action or decision based on any information contained in the Services. If, and before you make any financial, legal, or other decisions involving the Services, you should seek independent professional advice from an individual who is licensed and qualified in the area for which such advice would be appropriate.", - "Open-Source: Ten is being developed on an open-source basis under the GNU Affero General Public License, Version 3.0, the terms of which are found here: https://www.gnu.org/licenses/agpl-3.0.html (the “AGPLv3 Licence“). By accessing, using, copying (or similar) the Services, you agree that the Services shall be governed by the AGPLv3 Licence (and the Terms herein). The Services are licensed under the AGPLv3 License and you undertake that you will not use the Services except in compliance with the AGPLv3 License and these Terms. You agree that any software developed using the Services, shall be made available for the public to use on an open source basis, on the AGPLv3 License terms.", + "Open-Source: TEN is being developed on an open-source basis under the GNU Affero General Public License, Version 3.0, the terms of which are found here: https://www.gnu.org/licenses/agpl-3.0.html (the “AGPLv3 Licence“). By accessing, using, copying (or similar) the Services, you agree that the Services shall be governed by the AGPLv3 Licence (and the Terms herein). The Services are licensed under the AGPLv3 License and you undertake that you will not use the Services except in compliance with the AGPLv3 License and these Terms. You agree that any software developed using the Services, shall be made available for the public to use on an open source basis, on the AGPLv3 License terms.", "Compliance with Law. You represent and warrant that you will comply with all laws that apply to you, your use of the Services, and your actions and omissions that relate to the Services. If your use of the Services is prohibited by applicable laws, then you aren’t authorised to use the Services. We will not be responsible for your using the Services (and developing and/or deploying any software) in a way that is a violation of any law. Without limiting the foregoing, you represent and warrant that you are not, and for the duration of the time you use the Services (to develop any software or similar) will not be (a) the subject of economic or trade sanctions administered or enforced by any governmental authority or otherwise designated on any list of prohibited or restricted parties (including but not limited to the United Nations Security Council, the European Union, His Majesty’s Treasury, and U.S. Department of Treasury), or (b) a citizen, resident, or organised in a jurisdiction or territory that is the subject of comprehensive country-wide, territory-wide, or regional economic sanctions by the United Nations, European Union, any EU country, UK Treasury, or the United States, including without limitation Cuba, the Crimea, Donetsk, and Luhansk regions of Ukraine, Iran, North Korea, Russia, Syria, Yemen and any other regions and/or countries sanctioned from time to time. If at any point the above is no longer true, you must immediately cease using the Services.", "Assumption of Risk. By using the Services, you (a) represent that you are sophisticated enough to understand the various inherent risks of using cryptographic and public blockchain-based systems, including but not limited to the Services and digital assets, and (b) acknowledge and accept all such risks, and agree that we make no representations or warranties (expressly or implicitly) regarding, and that you will not hold us liable for those risks, including but not limited to the risks described below, any or all of which could lead to losses and damages, including the total and irrevocable loss of your assets. These risks include, but are not limited to:", "
  • Wallet security and safekeeping. You are solely responsible for the safeguarding and security of your Web3 wallets. If you lose your wallet seed phrase, private keys, or password, you may be forever unable to access your digital assets. Any unauthorised access to your wallet by third parties could result in the loss or theft of your digital assets. We have no involvement in, or responsibility for, storing, retaining, securing or recovering your Web3 wallet seed phrases, private keys, or passwords, or for any unauthorised access to your Web3 wallet.
  • Blockchain technology. Public blockchains, and the technology underlying and interacting with cryptographic and public blockchain-based systems, are experimental, inherently risky, and subject to change. Among other risks, bugs, malfunctions, cyberattacks, or changes to a particular public blockchain (e.g., via forks) could disrupt these technologies irreparably. There is no guarantee that any of these technologies will not become unavailable, degraded, or subject to hardware or software errors, operational or technical difficulties, denial-of-service attacks, other cyberattacks, or other problems requiring maintenance, interruptions, delays, or errors.
  • Network cost and performance. The cost, speed, and availability of transacting on public blockchain systems are subject to significant variability. There is no guarantee that any transfer will be confirmed or transferred successfully.
  • Blockchain transactions and smart contract execution. Public blockchain-based transactions (including but not limited to transactions automatically executed by smart contracts) are generally considered irreversible when confirmed. Any transaction that will interact with smart contracts or be recorded on a public blockchain must be recorded with extreme caution.
  • Digital assets. The markets for digital assets are nascent and highly volatile due to various risk factors including (but not limited to) adoption, speculation, technology, security, and regulation. Digital assets and their underlying blockchain networks are complex emerging technologies that may be subject to delays, halts or go offline as a result of errors, forks, attacks or other unforeseeable reasons. Anyone can create a digital asset, including fake versions of existing digital assets and digital assets that falsely claim to represent projects. So-called stablecoins may not be as stable as they purport to be, may not be fully or adequately collateralised, and may be subject to panics and runs. You are solely responsible for understanding the risks specific to each digital asset that is relevant to you.
  • Bridging. In addition to being an especially novel and untested implementation of blockchain technology in general, cross-blockchain bridging technology has historically been, and may in the future be, the subject of numerous cyberattacks and exploits, including without limitation, hacks that exploit a vulnerability in the associated software, hardware, systems or other equipment or social engineering to gain control of any bridge components, wallets, smart contracts or other related systems.
  • Control of the Services. The Services may be subject to periodic upgrades, which may introduce other risks, bugs, malfunctions, cyberattack vectors, or other changes to the Services that could disrupt the operation of the Services, the functionality of bridging, your ability to access bridged digital assets, or otherwise cause you damage or loss.
  • Third Party Risks. Third-party products carry their own individual, oftentimes highly significant risks. When you use the Services to interact with any third-party products, you are subject to all of those risks.
  • Legislative and regulatory risks. Digital assets, blockchain technology, and any related software and services are subject to legal and regulatory uncertainty in many jurisdictions. Legislative and regulatory changes or actions may adversely affect the usage, transferability, transactability and accessibility of digital assets, bridging or the Services.
", diff --git a/tools/walletextension/frontend/public/favicon/site.webmanifest b/tools/walletextension/frontend/public/favicon/site.webmanifest index ef69d666d6..9566669ebc 100644 --- a/tools/walletextension/frontend/public/favicon/site.webmanifest +++ b/tools/walletextension/frontend/public/favicon/site.webmanifest @@ -1,6 +1,6 @@ { - "name": "Ten Gateway", - "short_name": "Ten Gateway", + "name": "TEN Gateway", + "short_name": "TEN Gateway", "icons": [ { "src": "/android-chrome-192x192.png", diff --git a/tools/walletextension/frontend/src/components/modules/home/connected.tsx b/tools/walletextension/frontend/src/components/modules/home/connected.tsx index e180ad1670..cda7ee5193 100644 --- a/tools/walletextension/frontend/src/components/modules/home/connected.tsx +++ b/tools/walletextension/frontend/src/components/modules/home/connected.tsx @@ -23,9 +23,9 @@ const Connected = () => {

Connected Accounts

- Manage the accounts you have connected to the Ten Gateway. You can + Manage the accounts you have connected to the TEN Gateway. You can revoke access to your accounts at any time and request new tokens from - the Ten Discord. + the TEN Discord.

diff --git a/tools/walletextension/frontend/src/components/modules/home/disconnected.tsx b/tools/walletextension/frontend/src/components/modules/home/disconnected.tsx index 6e741517e8..0ba93f0672 100644 --- a/tools/walletextension/frontend/src/components/modules/home/disconnected.tsx +++ b/tools/walletextension/frontend/src/components/modules/home/disconnected.tsx @@ -15,21 +15,19 @@ import { DialogTrigger, } from "../../ui/dialog"; import Copy from "../common/copy"; -import { testnetUrls, tenChainIDDecimal } from "../../../lib/constants"; +import { + testnetUrls, + tenChainIDDecimal, + CONNECTION_STEPS, +} from "../../../lib/constants"; import { downloadMetaMask, ethereum } from "@/lib/utils"; -const CONNECTION_STEPS = [ - "Hit Connect to Ten and start your journey", - "Allow MetaMask to switch networks to the Ten Testnet", - "Sign the Signature Request (this is not a transaction)", -]; - const Disconnected = () => { const { connectToTenTestnet } = useGatewayService(); return (
-

Welcome to the Ten Gateway!

+

Welcome to the TEN Gateway!

Three clicks to setup encrypted communication between MetaMask and TEN.

@@ -52,12 +50,12 @@ const Disconnected = () => { - How does the Ten Gateway work? + How does the TEN Gateway work?

- By connecting your wallet to Ten and signing the signature request + By connecting your wallet to TEN and signing the signature request you will get a unique token, which is also your viewing key . It is contained in the RPC link and unique for each user.

@@ -71,7 +69,7 @@ const Disconnected = () => {

Signing the Signature Request is completely secure. It’s not a transaction so cannot spend any of your assets and it doesn’t give - Ten control over your account. + TEN control over your account.

@@ -106,7 +104,7 @@ const Disconnected = () => { > - {ethereum ? "Connect to Ten Testnet" : "Install MetaMask to continue"} + {ethereum ? "Connect to TEN Testnet" : "Install MetaMask to continue"}
diff --git a/tools/walletextension/frontend/src/lib/constants.ts b/tools/walletextension/frontend/src/lib/constants.ts index 70608fcc2d..6f0d22e968 100644 --- a/tools/walletextension/frontend/src/lib/constants.ts +++ b/tools/walletextension/frontend/src/lib/constants.ts @@ -14,22 +14,22 @@ export const GOOGLE_ANALYTICS_ID = process.env.NEXT_PUBLIC_GOOGLE_ANALYTICS_ID; export const testnetUrls = { sepolia: { - name: "Ten Testnet", + name: "TEN Testnet", url: "https://sepolia-testnet.ten.xyz", rpc: "https://rpc.sepolia-testnet.ten.xyz", }, uat: { - name: "Ten UAT-Testnet", + name: "TEN UAT-Testnet", url: "https://uat-testnet.ten.xyz", rpc: "https://rpc.uat-testnet.ten.xyz", }, dev: { - name: "Ten Dev-Testnet", + name: "TEN Dev-Testnet", url: "https://dev-testnet.ten.xyz", rpc: "https://rpc.dev-testnet.ten.xyz", }, default: { - name: "Ten Testnet", + name: "TEN Testnet", url: tenGatewayAddress, }, }; @@ -50,3 +50,9 @@ export const nativeCurrency = { symbol: "ETH", decimals: 18, }; + +export const CONNECTION_STEPS = [ + "Hit Connect to TEN and start your journey", + "Allow MetaMask to switch networks to the TEN Testnet", + "Sign the Signature Request (this is not a transaction)", +]; diff --git a/tools/walletextension/frontend/src/services/ethService.ts b/tools/walletextension/frontend/src/services/ethService.ts index 48993e9237..92d749b881 100644 --- a/tools/walletextension/frontend/src/services/ethService.ts +++ b/tools/walletextension/frontend/src/services/ethService.ts @@ -14,16 +14,17 @@ const ethService = { checkIfMetamaskIsLoaded: async (provider: ethers.providers.Web3Provider) => { try { if (ethereum) { - // There are some wallets that are conflicting with MetaMask - we want to check that and throw an error if they are connected const conflictingWalletMap = { - 'Exodus Wallet': ethereum.isExodus, - 'Nest Wallet': ethereum.isNestWallet, + "Exodus Wallet": ethereum.isExodus, + "Nest Wallet": ethereum.isNestWallet, // Add other wallets here as needed }; // Iterate over the wallet map and handle conflicts - for (const [walletName, isWalletConnected] of Object.entries(conflictingWalletMap)) { + for (const [walletName, isWalletConnected] of Object.entries( + conflictingWalletMap + )) { if (isWalletConnected) { const message = `${walletName} is connected and is conflicting with MetaMask. Please disable ${walletName} and try again.`; showToast(ToastType.DESTRUCTIVE, message); @@ -69,7 +70,7 @@ const ethService = { } else { return showToast( ToastType.WARNING, - "Please install MetaMask to use Ten Gateway." + "Please install MetaMask to use TEN Gateway." ); } } catch (error: any) { @@ -136,7 +137,7 @@ const ethService = { showToast(ToastType.INFO, "Getting accounts..."); if (!(await isTenChain())) { - showToast(ToastType.DESTRUCTIVE, "Please connect to the Ten chain."); + showToast(ToastType.DESTRUCTIVE, "Please connect to the TEN chain."); return; } diff --git a/tools/walletextension/frontend/src/services/useGatewayService.ts b/tools/walletextension/frontend/src/services/useGatewayService.ts index 5ce1e6a72d..3f0c5009cd 100644 --- a/tools/walletextension/frontend/src/services/useGatewayService.ts +++ b/tools/walletextension/frontend/src/services/useGatewayService.ts @@ -34,39 +34,39 @@ const useGatewayService = () => { }; const connectToTenTestnet = async () => { - showToast(ToastType.INFO, "Connecting to Ten Testnet..."); + showToast(ToastType.INFO, "Connecting to TEN Testnet..."); setLoading(true); try { if (await isTenChain()) { if (!token || !isValidTokenFormat(token)) { showToast( ToastType.DESTRUCTIVE, - "Existing Ten Testnet detected in MetaMask. Please remove before hitting begin" + "Existing TEN Testnet detected in MetaMask. Please remove before hitting begin" ); return; } } - showToast(ToastType.INFO, "Switching to Ten Testnet..."); + showToast(ToastType.INFO, "Switching to TEN Testnet..."); const switched = await switchToTenNetwork(); - showToast(ToastType.SUCCESS, `Switched to Ten Testnet: ${switched}`); + showToast(ToastType.SUCCESS, `Switched to TEN Testnet: ${switched}`); // SWITCHED_CODE=4902; error 4902 means that the chain does not exist if ( switched === SWITCHED_CODE || !isValidTokenFormat(await getToken(provider)) ) { - showToast(ToastType.INFO, "Adding Ten Testnet..."); + showToast(ToastType.INFO, "Adding TEN Testnet..."); const user = await joinTestnet(); const rpcUrls = [ `${tenGatewayAddress}/${tenGatewayVersion}/?token=${user}`, ]; await addNetworkToMetaMask(rpcUrls); - showToast(ToastType.SUCCESS, "Added Ten Testnet"); + showToast(ToastType.SUCCESS, "Added TEN Testnet"); } if (!(await isMetamaskConnected())) { showToast(ToastType.INFO, "No accounts found, connecting..."); await connectAccounts(); - showToast(ToastType.SUCCESS, "Connected to Ten Testnet"); + showToast(ToastType.SUCCESS, "Connected to TEN Testnet"); } await fetchUserAccounts(); } catch (error: any) { @@ -81,7 +81,7 @@ const useGatewayService = () => { try { return await fetchTestnetStatus(); } catch (error) { - showToast(ToastType.DESTRUCTIVE, "Unable to connect to Ten Testnet"); + showToast(ToastType.DESTRUCTIVE, "Unable to connect to TEN Testnet"); throw error; } }; diff --git a/tools/walletextension/lib/README.md b/tools/walletextension/lib/README.md index 4d0fd52ac1..36caa6dbd9 100644 --- a/tools/walletextension/lib/README.md +++ b/tools/walletextension/lib/README.md @@ -1 +1 @@ -A golang based library to use the ten gateway programmatically. \ No newline at end of file +A golang based library to use the TEN gateway programmatically. \ No newline at end of file diff --git a/tools/walletextension/main/cli.go b/tools/walletextension/main/cli.go index 16f1a00709..e1c4befd4d 100644 --- a/tools/walletextension/main/cli.go +++ b/tools/walletextension/main/cli.go @@ -55,7 +55,7 @@ const ( tenChainIDName = "tenChainID" tenChainIDDefault = 443 - tenChainIDFlagUsage = "ChainID of Ten network that the gateway is communicating with" + tenChainIDFlagUsage = "ChainID of TEN network that the gateway is communicating with" storeIncomingTxs = "storeIncomingTxs" storeIncomingTxsDefault = true diff --git a/tools/walletextension/rpcapi/blockchain_api.go b/tools/walletextension/rpcapi/blockchain_api.go index 36256559bf..3dc068b448 100644 --- a/tools/walletextension/rpcapi/blockchain_api.go +++ b/tools/walletextension/rpcapi/blockchain_api.go @@ -163,10 +163,10 @@ func (api *BlockChainAPI) GetCode(ctx context.Context, address gethcommon.Addres return *resp, err } -// GetStorageAt is not compatible with ETH RPC tooling. Ten network does not getStorageAt because it would +// GetStorageAt is not compatible with ETH RPC tooling. TEN network does not getStorageAt because it would // violate the privacy guarantees of the network. // -// However, we can repurpose this method to be able to route Ten-specific requests through from an ETH RPC client. +// However, we can repurpose this method to be able to route TEN-specific requests through from an ETH RPC client. // We call these requests Custom Queries. // // This method signature matches eth_getStorageAt, but we use the address field to specify the custom query method, diff --git a/tools/walletextension/rpcapi/debug_api.go b/tools/walletextension/rpcapi/debug_api.go index fc0452611d..77964306cf 100644 --- a/tools/walletextension/rpcapi/debug_api.go +++ b/tools/walletextension/rpcapi/debug_api.go @@ -48,7 +48,7 @@ func (api *DebugAPI) SetHead(number hexutil.Uint64) { // not implemented } -// EventLogRelevancy - specific to Ten - todo +// EventLogRelevancy - specific to TEN - todo func (api *DebugAPI) EventLogRelevancy(_ context.Context, _ common.Hash) (interface{}, error) { // todo return nil, rpcNotImplemented diff --git a/tools/walletextension/rpcapi/wallet_extension.go b/tools/walletextension/rpcapi/wallet_extension.go index 349a08b0d2..060ea5370f 100644 --- a/tools/walletextension/rpcapi/wallet_extension.go +++ b/tools/walletextension/rpcapi/wallet_extension.go @@ -37,8 +37,8 @@ import ( // Services handles the various business logic for the api endpoints type Services struct { - HostAddrHTTP string // The HTTP address on which the Ten host can be reached - HostAddrWS string // The WS address on which the Ten host can be reached + HostAddrHTTP string // The HTTP address on which the TEN host can be reached + HostAddrWS string // The WS address on which the TEN host can be reached Storage storage.Storage logger gethlog.Logger stopControl *stopcontrol.StopControl @@ -275,7 +275,7 @@ func (w *Services) Version() string { } func (w *Services) GetTenNodeHealthStatus() (bool, error) { - audit(w, "Getting Ten node health status") + audit(w, "Getting TEN node health status") res, err := withPlainRPCConnection[bool](context.Background(), w, func(client *gethrpc.Client) (*bool, error) { res, err := obsclient.NewObsClient(client).Health() return &res, err @@ -284,7 +284,7 @@ func (w *Services) GetTenNodeHealthStatus() (bool, error) { } func (w *Services) GetTenNetworkConfig() (tencommon.TenNetworkInfo, error) { - audit(w, "Getting Ten network config") + audit(w, "Getting TEN network config") res, err := withPlainRPCConnection[tencommon.TenNetworkInfo](context.Background(), w, func(client *gethrpc.Client) (*tencommon.TenNetworkInfo, error) { res, err := obsclient.NewObsClient(client).GetConfig() return res, err diff --git a/tools/walletextension/rpcapi/web3_api.go b/tools/walletextension/rpcapi/web3_api.go index c5e96dc663..78059a01e1 100644 --- a/tools/walletextension/rpcapi/web3_api.go +++ b/tools/walletextension/rpcapi/web3_api.go @@ -15,6 +15,6 @@ func NewWeb3API(we *Services) *Web3API { } func (api *Web3API) ClientVersion(_ context.Context) (*string, error) { - // todo: have this return the Ten version from the node + // todo: have this return the TEN version from the node return &_hardcodedClientVersion, nil }