diff --git a/.github/workflows/manual-deploy-obscuro-gateway-database.yml b/.github/workflows/manual-deploy-obscuro-gateway-database.yml
index 8fe3faaeb2..af448b43e7 100644
--- a/.github/workflows/manual-deploy-obscuro-gateway-database.yml
+++ b/.github/workflows/manual-deploy-obscuro-gateway-database.yml
@@ -88,7 +88,7 @@ jobs:
&& sudo apt-get install -y gcc \
&& sudo snap refresh && sudo snap install --channel=1.18 go --classic \
&& curl -fsSL https://get.docker.com -o get-docker.sh && sh ./get-docker.sh \
- && git clone --depth 1 -b ${{ env.BRANCH_NAME }} https://github.com/obscuronet/go-obscuro.git /home/obscuro/go-obscuro \
+ && git clone --depth 1 -b ${{ env.BRANCH_NAME }} https://github.com/ten-protocol/go-ten.git /home/obscuro/go-obscuro \
&& docker network create --driver bridge node_network || true \
&& docker run -d --name datadog-agent \
--network node_network \
diff --git a/.github/workflows/manual-deploy-obscuro-gateway.yml b/.github/workflows/manual-deploy-obscuro-gateway.yml
index 5e95506e53..e1f08b7131 100644
--- a/.github/workflows/manual-deploy-obscuro-gateway.yml
+++ b/.github/workflows/manual-deploy-obscuro-gateway.yml
@@ -104,7 +104,7 @@ jobs:
&& sudo apt-get install -y gcc \
&& sudo snap refresh && sudo snap install --channel=1.18 go --classic \
&& curl -fsSL https://get.docker.com -o get-docker.sh && sh ./get-docker.sh \
- && git clone --depth 1 -b ${{ env.BRANCH_NAME }} https://github.com/obscuronet/go-obscuro.git /home/obscuro/go-obscuro \
+ && git clone --depth 1 -b ${{ env.BRANCH_NAME }} https://github.com/ten-protocol/go-ten.git /home/obscuro/go-obscuro \
&& docker network create --driver bridge node_network || true \
&& docker run -d --name datadog-agent \
--network node_network \
diff --git a/.github/workflows/manual-deploy-obscuro-scan-2.yml b/.github/workflows/manual-deploy-obscuro-scan-2.yml
index 5433288240..aea11d479e 100644
--- a/.github/workflows/manual-deploy-obscuro-scan-2.yml
+++ b/.github/workflows/manual-deploy-obscuro-scan-2.yml
@@ -63,7 +63,7 @@ jobs:
name: ${{ github.event.inputs.testnet_type }}-fe-obscuro-scan
location: 'uksouth'
restart-policy: 'Never'
- environment-variables: VITE_APIHOSTADDRESS=http://${{ github.event.inputs.testnet_type }}-api-obscuro-scan.uksouth.azurecontainer.io VITE_FE_VERSION=${{ GITHUB.RUN_NUMBER }}-${{ GITHUB.SHA }}
+ environment-variables: VITE_APIHOSTADDRESS=https://${{ github.event.inputs.testnet_type }}-api.obscuroscan.io VITE_FE_VERSION=${{ GITHUB.RUN_NUMBER }}-${{ GITHUB.SHA }}
command-line: npm run serve-prod
ports: '80'
cpu: 2
diff --git a/.github/workflows/manual-deploy-testnet-l2.yml b/.github/workflows/manual-deploy-testnet-l2.yml
index 97c48e8a98..14dd0f91a8 100644
--- a/.github/workflows/manual-deploy-testnet-l2.yml
+++ b/.github/workflows/manual-deploy-testnet-l2.yml
@@ -202,7 +202,7 @@ jobs:
az vm run-command invoke -g Testnet -n "${{ vars.AZURE_RESOURCE_PREFIX }}-${{ matrix.host_id }}-${{ GITHUB.RUN_NUMBER }}" \
--command-id RunShellScript \
--scripts 'mkdir -p /home/obscuro \
- && git clone --depth 1 -b ${{ env.BRANCH_NAME }} https://github.com/obscuronet/go-obscuro.git /home/obscuro/go-obscuro \
+ && git clone --depth 1 -b ${{ env.BRANCH_NAME }} https://github.com/ten-protocol/go-ten.git /home/obscuro/go-obscuro \
&& docker network create --driver bridge node_network || true \
&& docker run -d --name datadog-agent \
--network node_network \
@@ -344,9 +344,9 @@ jobs:
- name: 'Send a repository dispatch to obscuro-test on deployment of dev-testnet'
if: ${{ (github.event.inputs.testnet_type == 'dev-testnet') }}
run: |
- curl -XPOST -H "Authorization: Bearer ${{ secrets.GH_TOKEN }}" -H "Accept:application/vnd.github" -H "Content-Type:application/json" https://api.github.com/repos/obscuronet/obscuro-test/dispatches --data '{ "event_type": "dev_testnet_deployed", "client_payload": { "ref": "${{ github.ref_name }}" }'
+ curl -XPOST -H "Authorization: Bearer ${{ secrets.GH_TOKEN }}" -H "Accept:application/vnd.github" -H "Content-Type:application/json" https://api.github.com/repos/ten-protocol/ten-test/dispatches --data '{ "event_type": "dev_testnet_deployed", "client_payload": { "ref": "${{ github.ref_name }}" }'
- name: 'Send a repository dispatch to obscuro-test on deployment of testnet'
if: ${{ (github.event.inputs.testnet_type == 'uat-testnet') }}
run: |
- curl -XPOST -H "Authorization: Bearer ${{ secrets.GH_TOKEN }}" -H "Accept:application/vnd.github" -H "Content-Type:application/json" https://api.github.com/repos/obscuronet/obscuro-test/dispatches --data '{ "event_type": "uat_testnet_deployed", "client_payload": { "ref": "${{ github.ref_name }}" }'
+ curl -XPOST -H "Authorization: Bearer ${{ secrets.GH_TOKEN }}" -H "Accept:application/vnd.github" -H "Content-Type:application/json" https://api.github.com/repos/ten-protocol/ten-test/dispatches --data '{ "event_type": "uat_testnet_deployed", "client_payload": { "ref": "${{ github.ref_name }}" }'
diff --git a/.github/workflows/manual-upgrade-testnet-l2.yml b/.github/workflows/manual-upgrade-testnet-l2.yml
index 562e386289..bc7e313976 100644
--- a/.github/workflows/manual-upgrade-testnet-l2.yml
+++ b/.github/workflows/manual-upgrade-testnet-l2.yml
@@ -147,7 +147,7 @@ jobs:
docker pull ${{ vars.L2_HOST_DOCKER_BUILD_TAG }} \
&& docker pull ${{ vars.L2_ENCLAVE_DOCKER_BUILD_TAG }} \
&& rm -rf /home/obscuro/go-obscuro \
- && git clone --depth 1 -b ${{ env.BRANCH_NAME }} https://github.com/obscuronet/go-obscuro.git /home/obscuro/go-obscuro \
+ && git clone --depth 1 -b ${{ env.BRANCH_NAME }} https://github.com/ten-protocol/go-ten.git /home/obscuro/go-obscuro \
&& cd /home/obscuro/go-obscuro/ \
&& sudo go run /home/obscuro/go-obscuro/go/node/cmd \
-is_genesis=${{ matrix.is_genesis }} \
@@ -212,12 +212,12 @@ jobs:
- name: 'Send a repository dispatch to obscuro-test on upgrade of dev-testnet'
if: ${{ github.event.inputs.testnet_type == 'dev-testnet' }}
run: |
- curl -XPOST -H "Authorization: Bearer ${{ secrets.GH_TOKEN }}" -H "Accept:application/vnd.github" -H "Content-Type:application/json" https://api.github.com/repos/obscuronet/obscuro-test/dispatches --data '{ "event_type": "dev_testnet_upgraded", "client_payload": { "ref": "${{ github.ref_name }}" }'
+ curl -XPOST -H "Authorization: Bearer ${{ secrets.GH_TOKEN }}" -H "Accept:application/vnd.github" -H "Content-Type:application/json" https://api.github.com/repos/ten-protocol/ten-test/dispatches --data '{ "event_type": "dev_testnet_upgraded", "client_payload": { "ref": "${{ github.ref_name }}" }'
- name: 'Send a repository dispatch to obscuro-test on upgrade of uat-testnet'
if: ${{ github.event.inputs.testnet_type == 'uat-testnet' }}
run: |
- curl -XPOST -H "Authorization: Bearer ${{ secrets.GH_TOKEN }}" -H "Accept:application/vnd.github" -H "Content-Type:application/json" https://api.github.com/repos/obscuronet/obscuro-test/dispatches --data '{ "event_type": "uat_testnet_upgraded", "client_payload": { "ref": "${{ github.ref_name }}" }'
+ curl -XPOST -H "Authorization: Bearer ${{ secrets.GH_TOKEN }}" -H "Accept:application/vnd.github" -H "Content-Type:application/json" https://api.github.com/repos/ten-protocol/ten-test/dispatches --data '{ "event_type": "uat_testnet_upgraded", "client_payload": { "ref": "${{ github.ref_name }}" }'
obscuro-test-signal-on-schedule:
runs-on: ubuntu-latest
@@ -228,4 +228,4 @@ jobs:
steps:
- name: 'Send a repository dispatch to obscuro-test on upgrade of dev-testnet'
run: |
- curl -XPOST -H "Authorization: Bearer ${{ secrets.GH_TOKEN }}" -H "Accept:application/vnd.github" -H "Content-Type:application/json" https://api.github.com/repos/obscuronet/obscuro-test/dispatches --data '{ "event_type": "dev_testnet_upgraded", "client_payload": { "ref": "${{ github.ref_name }}" }'
+ curl -XPOST -H "Authorization: Bearer ${{ secrets.GH_TOKEN }}" -H "Accept:application/vnd.github" -H "Content-Type:application/json" https://api.github.com/repos/ten-protocol/ten-test/dispatches --data '{ "event_type": "dev_testnet_upgraded", "client_payload": { "ref": "${{ github.ref_name }}" }'
diff --git a/.github/workflows/on-merged-pr.yml b/.github/workflows/on-merged-pr.yml
index 6ad171ece8..55d82af192 100644
--- a/.github/workflows/on-merged-pr.yml
+++ b/.github/workflows/on-merged-pr.yml
@@ -12,5 +12,5 @@ jobs:
steps:
- name: 'Trigger obscuro-test local testnet tun'
run: |
- curl -XPOST -H "Authorization: Bearer ${{ secrets.GH_TOKEN }}" -H "Accept:application/vnd.github" -H "Content-Type:application/json" https://api.github.com/repos/obscuronet/obscuro-test/dispatches --data '{ "event_type": "merged_pull_request", "client_payload": { "number": ${{ github.event.number }}, "owner": "${{ github.event.pull_request.user.login }}" } }'
+ curl -XPOST -H "Authorization: Bearer ${{ secrets.GH_TOKEN }}" -H "Accept:application/vnd.github" -H "Content-Type:application/json" https://api.github.com/repos/ten-protocol/ten-test/dispatches --data '{ "event_type": "merged_pull_request", "client_payload": { "number": ${{ github.event.number }}, "owner": "${{ github.event.pull_request.user.login }}" } }'
\ No newline at end of file
diff --git a/README.md b/README.md
index 685b53f384..53dda54b4f 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,6 @@
-# Go Obscuro
+# Go Ten
-This repository contains the reference implementation of the [Obscuro Protocol](https://whitepaper.obscu.ro/).
+This repository contains the reference implementation of the [Ten Protocol](https://whitepaper.obscu.ro/).
*Note that this is still very much a work in progress, so there are many rough edges and unfinished components.*
@@ -14,14 +14,14 @@ The typical blockchain node runs multiple services in a single process. For exam
- Mempool
- etc
-Obscuro 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 Obscuro 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
-Obscuro 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,10 +59,10 @@ 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 Obscuro 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.obscu.ro/obscuro-whitepaper/detailed-design.html#revelation-mechanism), the blocks have to be checked for validity, which includes checking that enough "work" went into them.
+[revelation period](https://whitepaper.obscu.ro/ten-whitepaper/detailed-design.html#revelation-mechanism), the blocks have to be checked for validity, which includes checking that enough "work" went into them.
To achieve this we depend on the [Blockchain](https://github.com/ethereum/go-ethereum/blob/e6fa102eb08c2b83ab75e85ca7860eea3a10dab0/core/blockchain.go)
logic.
@@ -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.
-Obscuro 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, Obscuro 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 Obscuro.
+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 Obscuro, every node receiving the same block containing the rollup and the deposits, will generate the exact same synthetic transaction.
+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
-Obscuro ERC20 transactions sent to a special "Bridge" address are interpreted as withdrawals. Which means the wrapped tokens are burned
-on the Obscuro 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 Obscuro 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 Obscuro 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 Obscuro "Wallet extension" encrypts all requests from users (transactions or smart contract method calls) with the "Obscuro 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 "Obscuro 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 Obscuro node and its clients.
+between the Ten node and its clients.
See the [docs](https://docs.obscu.ro/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 Obscuro cryptography.
+│ │ ├── crypto: Implementation of the Ten cryptography.
│ │ ├── db: The database implementations.
│ │ ├── enclaverunner: The entry point to the standalone enclave process.
-│ │ ├── evm: Obscuro 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 Obscuro 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 Obscuro 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.
- ├── obscuroscan: Tooling to monitor network transactions.
- └── walletextension: Ensures sensitive messages to and from the Obscuro node are encrypted.
+ ├── tenscan: Tooling to monitor network transactions.
+ └── walletextension: Ensures sensitive messages to and from the Ten node are encrypted.
## Testing
-The Obscuro 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 Obscuro 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 obscuro 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,10 +269,10 @@ of these setups by receiving RPC handles to the nodes.
## Getting Started
-The following section describes building the reference implementation of the Obscuro protocol, running the unit and
-integration tests, and deploying a local testnet for end-to-end testing. The reference implementation of Obscuro 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-obscuro` checkout.
+`go-ten` checkout.
### Dependencies
@@ -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 Obscuro 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;
@@ -325,7 +325,7 @@ docker images repository use;
```
./testnet/testnet-local-build_images.sh \
&& go run ./testnet/launcher/cmd \
-&& ./testnet/start-obscuroscan.sh --rpcServerAddress=http://localhost:80 --receivingPort=8098
+&& ./testnet/start-tenscan.sh --rpcServerAddress=http://localhost:80 --receivingPort=8098
```
The above will perform all the relevant builds and ensure the images are ready for running each component.
@@ -334,28 +334,28 @@ Will then start each component with the alloted defaults. ~3-6 mins to complete
The defaults used are:
- `0x13E23Ca74DE0206C56ebaE8D51b5622EFF1E9944` is the public address of the pre-funded account on the L1 network used
-to deploy the Obscuro Management and the ERC20 contracts
+to deploy the Ten Management and the ERC20 contracts
- `0x0654D8B60033144D567f25bF41baC1FB0D60F23B` is the public address of the pre-funded account on the L1 network used to
-pay for Obscuro rollup transactions
+pay for Ten rollup transactions
- `f52e5418e349dccdda29b6ac8b0abe6576bb7713886aa85abea6181ba731f9bb` is the private key of the pre-funded
-account on the L1 network used to deploy the Obscuro Management and the ERC20 contracts
-- `0x0000000000000000000000000000000000000001` is the host id of the Obscuro node when starting in a local mode
-- `0xeDa66Cc53bd2f26896f6Ba6b736B1Ca325DE04eF` is the address of the Obscuro Management contract which is known a-priori as a nonce of 0 is used
-- `0xC0370e0b5C1A41D447BDdA655079A1B977C71aA9` is the address of the ERC20 contract which represents OBX and is known a-priori as a nonce of 1 is used
+account on the L1 network used to deploy the Ten Management and the ERC20 contracts
+- `0x0000000000000000000000000000000000000001` is the host id of the Ten node when starting in a local mode
+- `0xeDa66Cc53bd2f26896f6Ba6b736B1Ca325DE04eF` is the address of the Ten Management contract which is known a-priori as a nonce of 0 is used
+- `0xC0370e0b5C1A41D447BDdA655079A1B977C71aA9` is the address of the ERC20 contract which represents TEN and is known a-priori as a nonce of 1 is used
- `0x51D43a3Ca257584E770B6188232b199E76B022A2` is the address of the ERC20 contract which represents ETH and is known a-priori as a nonce of 2 is used
-Once started Obscuroscan is available on `http://0.0.0.0:8098`.
+Once started Tenscan is available on `http://0.0.0.0:8098`.
### Building and running a local faucet
-Deploying and interacting with contracts on Obscuro requires ETH to be allocated to an account on the L2 via the faucet (or bridged across from the L1).
+Deploying and interacting with contracts on Ten requires ETH to be allocated to an account on the L2 via the faucet (or bridged across from the L1).
The faucet image should be pulled (or optionally built from scratch), and the container built and started to allow requests to be made to it.
To pull the testnet faucet and run use;
```
cd tools/faucet
docker pull testnetobscuronet.azurecr.io/obscuronet/faucet_sepolia_testnet:latest
-./container_run.sh -image testnetobscuronet.azurecr.io/obscuronet/faucet_sepolia_testnet:latest
+./container_run.sh -image testnetobscuronet.azurecr.io/obscuronet/faucet_sepolia_testnet:latest
```
The faucet runs a web server within the container, with a port mapping of 8080 set to allow POST requests to be made to
@@ -370,12 +370,12 @@ curl --location --request POST 'http://127.0.0.1:8080/fund/eth' \
### Deploying contracts into a local testnet
-Deploying and interacting with contracts on Obscuro requires the wallet extension to be running. The wallet extension is
-the Obscuro component that ensures that sensitive information in RPC requests between client applications and Obscuro
+Deploying and interacting with contracts on Ten requires the wallet extension to be running. The wallet extension is
+the Ten component that ensures that sensitive information in RPC requests between client applications and Ten
cannot be seen by third parties. The wallet extension should be run local to the client application and is described in
more detail at [docs/wallet-extension/wallet-extension.md](docs/wallet-extension/wallet-extension.md).
-To start the wallet extension to run against a local testnet, in the go-obscuro repo use the below;
+To start the wallet extension to run against a local testnet, in the go-ten repo use the below;
```
cd ./tools/walletextension/main/
diff --git a/contracts/README.md b/contracts/README.md
index d020f6c32b..3e4a2081b6 100644
--- a/contracts/README.md
+++ b/contracts/README.md
@@ -1,6 +1,6 @@
-# Obscuro smart contracts
+# Ten smart contracts
-This hardhat project contains the relevant smart contracts for the Obscuro 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 Obscuro 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 `obscuro: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 `obscuroEncRpcUrl` property to the rpc endpoint of the obscuro node the wallet will connect to.
+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.
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/deployment_scripts/testnet/layer1/002_add_bridge_admin.ts b/contracts/deployment_scripts/testnet/layer1/002_add_bridge_admin.ts
index 8c8c425f92..2fdab0fba0 100644
--- a/contracts/deployment_scripts/testnet/layer1/002_add_bridge_admin.ts
+++ b/contracts/deployment_scripts/testnet/layer1/002_add_bridge_admin.ts
@@ -18,7 +18,11 @@ const func: DeployFunction = async function (hre: HardhatRuntimeEnvironment) {
// Deploy a constant supply (constructor mints) erc20
await deployments.execute('ObscuroBridge', {
from: deployer
- }, 'promoteToAdmin', '0xE09a37ABc1A63441404007019E5BC7517bE2c43f')
+ }, 'promoteToAdmin', '0xE09a37ABc1A63441404007019E5BC7517bE2c43f');
+
+ await deployments.execute('ObscuroBridge', {
+ from: deployer
+ }, 'promoteToAdmin', '0xeC3f9B38a3B30AdC9fB3dF3a0D8f50127E6c2C8f');
};
export default func;
diff --git a/contracts/src/README.md b/contracts/src/README.md
index ca65af03c9..5c858ab6b8 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 Obscuro - 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 c16a9f1d1e..4ac7ca164e 100644
--- a/design/README.md
+++ b/design/README.md
@@ -1,6 +1,6 @@
-# Obscuro design documents
+# Ten design documents
-Obscuro started based on a (whitepaper)[https://whitepaper.obscu.ro/] published in Nov. 2021.
+Ten started based on a (whitepaper)[https://whitepaper.obscu.ro/] 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
-Obscuro 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
-Obscuro 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 1afbdb6662..adf98da79e 100644
--- a/design/architecture/overall_design.md
+++ b/design/architecture/overall_design.md
@@ -1,24 +1,24 @@
-# Obscuro design
+# Ten design
## Scope
-The purpose of this document is to describe aspects of Obscuro's technical design that are not addressed in the
-[Obscuro whitepaper](https://whitepaper.obscu.ro/).
+The purpose of this document is to describe aspects of Ten's technical design that are not addressed in the
+[Ten whitepaper](https://whitepaper.obscu.ro/).
## Overview
-The following diagram shows the key components of an Obscuro 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 Obscuro node that runs inside a trusted execution environment (TEE)
-* **The host:** The remainder of the Obscuro node that runs outside the TEE
-* **The Obscuro management contract:** The Ethereum mainnet contracts required by the Obscuro protocol, described
- [here](https://whitepaper.obscu.ro/obscuro-whitepaper/l1-contracts)
-* **Client apps:** Applications that interact with the Obscuro node (e.g. Obscuro wallets)
+* **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.obscu.ro/ten-whitepaper/l1-contracts)
+* **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 Obscuro 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/architecture/tech_decisions.md b/design/architecture/tech_decisions.md
index c897f1dae3..cdcea1562b 100644
--- a/design/architecture/tech_decisions.md
+++ b/design/architecture/tech_decisions.md
@@ -1,12 +1,12 @@
# Tech decisions
-This document lists the frameworks and tooling used by Obscuro.
+This document lists the frameworks and tooling used by Ten.
The purpose of this list is to avoid the proliferation of different frameworks and tooling with the same general
-purpose, as this increases the developer overhead when extending Obscuro.
+purpose, as this increases the developer overhead when extending Ten.
The introduction of a new framework or tool should be discussed with the team, even if the usage sits outside the
-`go-obscuro` repo.
+`go-ten` repo.
## Deployment
diff --git a/design/bridge/bridge_design.md b/design/bridge/bridge_design.md
index 0e05fd1517..38e1240f04 100644
--- a/design/bridge/bridge_design.md
+++ b/design/bridge/bridge_design.md
@@ -1,10 +1,10 @@
-# Obscuro 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 Obscuro. 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!
+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 Obscuro 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 Obscuro 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,32 +23,32 @@ 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 Obscuro 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 Obscuro
- * The bridge will have an asset whitelist controlled and configured by the management contract. Later this will be managed by the Obscuro DAO.
+ * 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.
* 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 Obscuro 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 Obscuro and Mainnet Ethereum.
+* Messaging architecture between Ten and Mainnet Ethereum.
* Basic Bridge that wraps assets
* Primitive fees implementation
## Assumptions
1. Fees
- * Big assumption - there will be a way to pay for bridge services/messaging in OBX without incurring losses in ETH on the layer 1 side.
- * The Obscuro 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.
+ * 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.
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.
- * Obscuro has fast finality over the transaction ordering rather than the results. When a deposit gets reorganized the results on Obscuro 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 Obscuro 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 - Obscuro 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 Obscuro 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 Obscuro 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 Obscuro 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.
@@ -196,37 +196,37 @@ When a block from `L1` is processed by the `enclave` and transactions inside of
When a transaction on the `L2` results in `LogMessagePublished`, the event will automatically be added to the `Rollup header` by the `enclave`. Then the management contract will submit them to the `MessageBus` or they will directly be.
-![Diagram not found](./resources/PublishFromObscuro.svg)
+![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 Obscuro 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. Obscuro 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 neccessary.
+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 neccessary.
* 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. Obscuro 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 Obscuro 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: Obscuro 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 Obscuro 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 Obscuro 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 Obscuro L2 will be different from the native currency on L1 - ETH. This means `ETH : OBX` 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`.
* This is a bad user experience. Anytime we want to withdraw we must source `WETH`
* It does protect us from losing money when publishing rollups, however.
-2. Using a DEX when it becomes available on Obscuro's L2 we can exchange OBX tokens for the required amount of `WETH`.
+2. Using a DEX when it becomes available on Ten's L2 we can exchange TEN tokens for the required amount of `WETH`.
An additional insurance fee might be required. It is described in [Security](#MessageBusSecurity)
@@ -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 Obscuro 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.
@@ -265,7 +265,7 @@ This diagrams should help illustrate the control flow:
We can also engineer a mechanism to insure delivered messages:
* When fees are collected for `publishMessage`, part of those fees is funneled to an insurance pool.
-* When a message that has been published gets reorganized the ObscuroDAO can pay for the financial loss from the insurance pool.
+* When a message that has been published gets reorganized the TenDAO can pay for the financial loss from the insurance pool.
> **_NOTE:_** The maximum possible payout should always be less than the penalty for PoS slashing on MainNet. This ensures there is no profit to attacking and claiming insurance.
@@ -310,11 +310,11 @@ There will be the following topics initially:
---
-**Diagram of the bridge process that happens on Obscuro's Layer 2 when a deposit is created**
-![Sequence Diagram not available](./resources/ObscuroL2_MessageBus_deposit_Diagram.svg)
+**Diagram of the bridge process that happens on Ten's Layer 2 when a deposit is created**
+![Sequence Diagram not available](./resources/TenL2_MessageBus_deposit_Diagram.svg)
-**Diagram of the process to withdraw the assets from the bridge contract on Obscuro's Layer 2**
-![Sequence Diagram not available](./resources/ObscuroL2_Bridge_withdraw_Diagram.svg)
+**Diagram of the process to withdraw the assets from the bridge contract on Ten's Layer 2**
+![Sequence Diagram not available](./resources/TenL2_Bridge_withdraw_Diagram.svg)
The API to transfer assets from the perspective of the user is the same on both layers. The process is as follows:
@@ -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 Obscuro and Eth. If Obscuro 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 7093f874e2..fe580895ef 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 Obscuro 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 Obscuro 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 Obscuro protocol from some external data, with the intent of
-bringing that data on the Obscuro chain, since these transactions will be addressed to a "system contract".
-Every Obscuro 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.
@@ -64,11 +64,11 @@ There are two main disadvantages.
The first is that users must wait before bridge messages are processed, which is not a great UX and it disables certain applications.
The second is that the security of the funds on the bridge depends on the delay. If the delay is x Ethereum blocks, then
-an attacker must wait for x blocks until the deposit executes on Obscuro, and then perform a revert attack on Ethereum.
+an attacker must wait for x blocks until the deposit executes on Ten, and then perform a revert attack on Ethereum.
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 Obscuro 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 2fdd843ceb..cd5b620e5e 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 Obscuro 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 Obscuro 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
-Obscuro 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 be83e10801..74763326eb 100644
--- a/design/finality_protocol/sequencer_bootstrapping_strategy.md
+++ b/design/finality_protocol/sequencer_bootstrapping_strategy.md
@@ -2,24 +2,24 @@
*Note: this document is still a WIP*
-As we are getting closer to production and have already designed implemented the key components of Obscuro, it's time to think about our bootstrapping strategy.
+As we are getting closer to production and have already designed implemented the key components of Ten, it's time to think about our bootstrapping strategy.
The POBI protocol described in the whitepaper assumes a network with significant traction.
-To get there, we estimate Obscuro 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 Obscuro 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 Obscuro Foundation, and is configured as a variable in the Obscuro 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 Obscuro 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.
@@ -124,7 +124,7 @@ The solution is to delegate the work of replying to users to the entire network
#### Incentives for L2 node operators
-See the incentives design in go-obscuro.
+See the incentives design in go-ten.
#### Proposal for a protocol to keep L2 nodes in sync
@@ -154,7 +154,7 @@ After N such light rounds, when the Aggregator has gathered enough txs, it submi
##### The batch as the canonical unit
-In the scenario, from the point of view of the ObscuroVM, each batch is the equivalent to an Ethereum block.
+In the scenario, from the point of view of the TenVM, each batch is the equivalent to an Ethereum block.
The rollups published to the L1 function more like logical checkpoints.
diff --git a/design/scratchpad/Design_escape_hatch.md b/design/scratchpad/Design_escape_hatch.md
index a2f88c767d..30861a6a0f 100644
--- a/design/scratchpad/Design_escape_hatch.md
+++ b/design/scratchpad/Design_escape_hatch.md
@@ -1,9 +1,9 @@
-# Design for the Obscuro escape hatch
+# Design for the Ten escape hatch
*Note: this document is still a WIP*
This document proposes a design for an "Escape Hatch".
-It describes the ultimate way by which users can exit Obscuro.
+It describes the ultimate way by which users can exit Ten.
## High level requirement
@@ -11,7 +11,7 @@ It describes the ultimate way by which users can exit Obscuro.
The "escape hatch" is the mechanism that kicks in when **all hope is lost**, the last resort.
Something that happens just before the network goes down permanently for some unforseen reason.
-For example, wen the central sequencer is no longer able to produce blocks and the Obscuro foundation is unable to replace it with something working in due time.
+For example, wen the central sequencer is no longer able to produce blocks and the Ten foundation is unable to replace it with something working in due time.
The high level requirement is that even in this situation, users should be able to exit the funds they have locked up in the bridge.
diff --git a/design/security/Escape_hatch.md b/design/security/Escape_hatch.md
index 001d58a8d6..4ecfaf75ec 100644
--- a/design/security/Escape_hatch.md
+++ b/design/security/Escape_hatch.md
@@ -1,7 +1,7 @@
## Handling catastrophic events
-Obscuro 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 Obscuro 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 5b9bd8268d..929e2a396f 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 Obscuro Enclave
+# An objective source of truth for the Ten Enclave
-A TEE-based network like Obscuro 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.
-Obscuro 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
-Obscuro 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: Obscuro 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 Obscuro Upgrades
+### Transparent Ten Upgrades
-A TEE-based system like Obscuro 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 Obscuro 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
-Obscuro 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 Obscuro node has to periodically publish a transaction to Bitcoin.
-One immediate improvement is for the Obscuro 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 Obscuro network
+#### Solution 2 - Nonce validated by the Ten network
-Another potential solution is to rely on the Obscuro network itself to validate the randomness.
-This is more tricky to achieve because of the subjectivity of the Obscuro 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 Obscuro 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 Obscuro 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 a519e050c7..e051d61384 100644
--- a/design/security/Upgrade_Design.md
+++ b/design/security/Upgrade_Design.md
@@ -1,7 +1,7 @@
-# Obscuro Upgrades
+# Ten Upgrades
-This design covers the operational aspects of upgrading Obscuro.
-The mechanism by which the community validates an upgrade is covered in the [Obscuro source of truth](./Source_of_truth.md) document.
+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.
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 Obscuro 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.
-### Obscuro secrets
+### Ten secrets
-There are two main secrets on an Obscuro 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: Obscuro 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,11 +36,11 @@ 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.
-- Obscuro 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.
-## Upgrade reasons for Obscuro
+## Upgrade reasons for Ten
1. To fix security bugs which can impact the integrity of the ledger.
1. To fix security bugs that can impact the ledger's privacy.
@@ -87,7 +87,7 @@ They can implement the change such that the previous version does not crash when
There are multiple issues with this option. It was used mostly in the early days, but currently, the "hard fork" approach
with a block number activation date is the preferred option.
-In Obscuro, we'll use the preferred Ethereum approach.
+In Ten, we'll use the preferred Ethereum approach.
### 2. Local only upgrades
@@ -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 Obscuro (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.
-## Obscuro 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 Obscuro 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 Obscuro nodes via RPC.
-For a good UX, Obscuro 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 Obscuro 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 Obscuro 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/cryptography.md b/design/security/cryptography.md
index 37dc3724a1..e6a4495386 100644
--- a/design/security/cryptography.md
+++ b/design/security/cryptography.md
@@ -1,6 +1,6 @@
-# Obscuro cryptography
+# Ten cryptography
-Obscuro uses cryptography for:
+Ten uses cryptography for:
- data authentication
- integrity
- Private communication and data storage.
@@ -27,7 +27,7 @@ will get verified by the other nodes who have the power to challenge.
## Private communication and data storage
-Privacy is a concern that is Obscuro-specific.
+Privacy is a concern that is Ten-specific.
For protecting data-in-use we use SGX.
@@ -36,7 +36,7 @@ In this section we'll discuss how data is protected in transit and at rest.
### The Shared Secret
-Obscuro is a decentralised network of attested nodes that need to collaborate on building a ledger.
+Ten is a decentralised network of attested nodes that need to collaborate on building a ledger.
The ledger should only be visible inside the enclave program, and not to the outside world.
The requirement is that all data exiting the enclaves should be encrypted with keys known only to the enclaves.
@@ -58,16 +58,16 @@ and for receiving encrypted responses which only that user can decrypt.
VKs are signed by the actual account key as part of a transaction. This is the only step that requires a human interaction.
-VKs are certificates used behind the scenes by the Obscuro tooling to encrypt and authenticate traffic.
+VKs are certificates used behind the scenes by the Ten tooling to encrypt and authenticate traffic.
### Data in transit
By data in transit, we mean a few things:
- transactions submitted by end users.
- "eth_call" requests. Users calling smart contracts
-- protocol communication between obscuro nodes (not yet used, so not covered).
+- protocol communication between ten nodes (not yet used, so not covered).
-#### The "Obscuro Key"
+#### The "Ten Key"
Client software must encrypt data with a key known only to the enclaves.
@@ -87,9 +87,9 @@ Data at rest is:
#### EdgelessDB
-Obscuro uses EdglessDB as the local database, the equivalent of LevelDB in go-ethereum.
+Ten uses EdglessDB as the local database, the equivalent of LevelDB in go-ethereum.
-EdgelessDB runs inside an enclave. After the initial handshake attestation, the Obscuro Enclave will store the key
+EdgelessDB runs inside an enclave. After the initial handshake attestation, the Ten Enclave will store the key
used for communication with Edgeless sealed with the enclave key.
Edb uses RocksDB behind the scenes and use AES-GCM to encrypt the backing files.
@@ -115,17 +115,17 @@ The advantage of releasing keys, as opposed to releasing decrypted transactions
#### Storing transactions in batches
-Batches are the units of data gossiped between the Obscuro nodes that provide soft finality.
+Batches are the units of data gossiped between the Ten nodes that provide soft finality.
The payload of each batch is encrypted with a:
`Key_for_Batch(Batch_Height)=HKDF(SHA256(BatchHeight || Shared_secret))` (Todo - does this make sense?)
## SGX Attestation Parameters
-In order for the Obscuro enclave to be considered secure, besides the actual code running on up-to-date hardware, it also must be
+In order for the Ten enclave to be considered secure, besides the actual code running on up-to-date hardware, it also must be
configured with the right parameters.
-The requirement is that a node operator should not be able to start an Obscuro Enclave (and obtain the Shared Secret) with
+The requirement is that a node operator should not be able to start an Ten Enclave (and obtain the Shared Secret) with
parameters that allow them to extract secrets.
Some configs will not change from one version to the nex, but must be configurable because the same codebase is used for both testing and production.
@@ -137,7 +137,7 @@ The config file passed in will be included in the enclave measurement.
### Protected config parameters
#### Business configs
-- Obscuro Chain Id
+- Ten Chain Id
- Ethereum Chain Id
- Management Contract Address
- MessageBus Address
diff --git a/design/security/high_availability.md b/design/security/high_availability.md
index d09aabc1a6..73634d74e5 100644
--- a/design/security/high_availability.md
+++ b/design/security/high_availability.md
@@ -1,6 +1,6 @@
# High availability
-The Obscuro 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 Obscuro 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 Obscuro network
+An alternative solution is to introduce transparency into the lifecycle events of the sequencer enclaves, such that the Ten network
can assess the likelyhood 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 Obscuro 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 3036bc80a1..e9c5effc49 100644
--- a/design/security/randomness_design.md
+++ b/design/security/randomness_design.md
@@ -1,8 +1,8 @@
-# Randomness in Obscuro design
+# Randomness in Ten design
## Scope
-The purpose of this document is to describe how randomness is generated and exposed to Obscuro smart contracts.
+The purpose of this document is to describe how randomness is generated and exposed to Ten smart contracts.
## Overview
@@ -10,7 +10,7 @@ In the latest version of Ethereum, smart contract developers generally use the `
This randomness is visible and known to everyone, and somehow under the control of the miners.
## Requirements
-In Obscuro, our goal is to remove any control that the miners might have over randomness, while also keeping the randomness private per transaction.
+In Ten, our goal is to remove any control that the miners might have over randomness, while also keeping the randomness private per transaction.
This enables use cases such as games with hidden state.
## Solution
diff --git a/design/ux/Events_design.md b/design/ux/Events_design.md
index b48a461805..444ef55464 100644
--- a/design/ux/Events_design.md
+++ b/design/ux/Events_design.md
@@ -1,8 +1,8 @@
-# Events in Obscuro - Design document
+# Events in Ten - Design document
## Scope
-This is a design proposal for how to handle events in Obscuro.
+This is a design proposal for how to handle events in Ten.
It covers two aspects:
@@ -23,7 +23,7 @@ It covers two aspects:
## Event visibility design
-In Obscuro, we aim to maintain the same events APIs that are found in Ethereum, and will try to implement privacy
+In Ten, we aim to maintain the same events APIs that are found in Ethereum, and will try to implement privacy
concerns with as few changes as possible. For background on how Ethereum handles events, see the section
"Background - Ethereum Events Design", below.
@@ -38,7 +38,7 @@ To decide whether a user Alice is entitled to view an event, we must consider th
### Event visibility rules
-Each event contains an array of 32-byte hex strings, called topics. In Obscuro, as in Ethereum, end-users are
+Each event contains an array of 32-byte hex strings, called topics. In Ten, as in Ethereum, end-users are
identified by one or more account addresses. Since we are reusing Ethereum's API without modifications, our goal is to
use an event's topics to ascertain who the event is relevant to, with users able to see an event if and only if the
event is considered relevant to them.
@@ -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 Obscuro 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 Obscuro 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 Obscuro 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.
-## Obscuro 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.
-### Obscuro 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.
-### Obscuro 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.
-### Obscuro 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 Obscuro 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/Obscuro_Gateway.md b/design/ux/Obscuro_Gateway.md
index 78df291b84..6c58a31d28 100644
--- a/design/ux/Obscuro_Gateway.md
+++ b/design/ux/Obscuro_Gateway.md
@@ -1,6 +1,6 @@
-# The Obscuro Gateway - Design
+# The Ten Gateway - Design
-The scope of this document is to design a hosted [Wallet Extension](wallet_extension.md) called the "Obscuro Gateway" (OG).
+The scope of this document is to design a hosted [Wallet Extension](wallet_extension.md) called the "Ten Gateway" (OG).
The OG 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 OG must support mutiple users, each with multiple addresses. It can be seen as offering a WE per user.
-The Obscuro 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 Obscuro 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 OG is implemented.
@startuml
'https://plantuml.com/deployment-diagram
-cloud "Obscuro 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" ----> "Obscuro 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 "Obscuro Gateway"
+ node "Ten Gateway"
database "OG Viewing Keys"
}
-"OG Viewing Keys" <-> "Obscuro Gateway"
+"OG Viewing Keys" <-> "Ten Gateway"
Bob --> "Bob's MetaMask"
-"Bob's MetaMask" ---> "Obscuro Gateway" : HTTPS
-"Obscuro Gateway" ----> "Obscuro 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 "Obscuro Gateway"
+node "Ten Gateway"
Charlie --> "Charlie's MetaMask"
-"Charlie's MetaMask" ---> "Obscuro Gateway" : HTTPS
+"Charlie's MetaMask" ---> "Ten Gateway" : HTTPS
@enduml
```
@@ -86,11 +86,11 @@ autonumber
actor "Alice's Browser" as Alice
participant MetaMask as MM
-participant "https://gateway.obscuro.network/v1" as OG
-participant "https://obscuro.network" as ON
+participant "https://gateway.ten.org/v1" as OG
+participant "https://ten.org" as ON
group First click
- Alice -> ON: Join Obscuro
+ Alice -> ON: Join Ten
ON --> Alice: Redirect to OG
note right
The point of this sequence
@@ -104,11 +104,11 @@ group First click
the Public Key of the VK
end note
OG -> Alice: Send UserId
- Alice -> MM: Automatically add "Obscuro" network with RPC\n"https://gateway.obscuro.network/v1?u=$UserId"
+ Alice -> MM: Automatically add "Ten" network with RPC\n"https://gateway.ten.org/v1?u=$UserId"
end
group Second click
- Alice -> MM : Connect wallet and switch to Obscuro
+ Alice -> MM : Connect wallet and switch to Ten
end
group Third click
@@ -121,42 +121,42 @@ group Third click
Alice -> MM : Confirm signature
end
-Alice -> OG: All further Obscuro interactions will be to\nhttps://gateway.obscuro.network/v1?u=$UserId
+Alice -> OG: All further Ten interactions will be to\nhttps://gateway.ten.org/v1?u=$UserId
@enduml
```
The onboarding should be done in 3 clicks.
-1. The user goes to a website (like "obscuro.network"), where she clicks "Join Obscuro". 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 a message: "Register $UserId for $ACCT"
##### Click 1
-1. Behind the scenes, a js functions calls "gateway.obscuro.network/v1/join" where it will generate a VK and send back the hash of the Public key. This is the "UserId"
+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 "UserId"
2. After receiving the UserId, the js function will add a new network to the wallet.
-The RPC URL of the new Obscuro network will include the userid: "https://gateway.obscuro.network/v1?u=$UserId".
+The RPC URL of the new Ten network will include the userid: "https://gateway.ten.org/v1?u=$UserId".
Notice that the UserId has to be included as a query parameter because it must be encrypted by https, as it is secret.
##### Click 2
-After these actions are complete, the same page will now ask the user to connect the wallet and switch to Obscuro.
+After these actions are complete, the same page will now ask the user to connect the wallet and switch to Ten.
Automatically the page will open metamask and ask the user to sign over a text "Register $UserId for $ACCT", where ACCT is the current account selected in metamask.
##### Click 3
-Once signed, this will be submitted in the background to: "https://gateway.obscuro.network/v1?u=$UserId&action=register"
+Once signed, this will be submitted in the background to: "https://gateway.ten.org/v1?u=$UserId&action=register"
Note: Any further accounts will be registered similarly for the same UserId.
Note: The user must guard the UserId. Anyone who can read it, will be able to read the data of this user.
-The ultimate goal of this protocol is to submit the "Register $UserId for $ACCT" text to the gateway, which is required by an Obscuro node to authenticate viewing keys per address.
+The ultimate goal of this protocol is to submit the "Register $UserId for $ACCT" text to the gateway, which is required by an Ten node to authenticate viewing keys per address.
Note: Alternative UXes that achieve the same goal are ok.
### Register subsequent addresses
-User Alice is onboarded already and has the Obscuro network configured in her wallet with a UserId.
+User Alice is onboarded already and has the Ten network configured in her wallet with a UserId.
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 7e345ba8f5..5a779bc183 100644
--- a/design/ux/block_explorer.md
+++ b/design/ux/block_explorer.md
@@ -2,7 +2,7 @@
## Scope
-The design for the Obscuro block explorers, tools to allow users to make sense of the contents of the Obscuro 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.
@@ -56,7 +56,7 @@ useful view to the customer. For example, a user may wish to view all the transf
contract, which requires walking the chain and storing the results locally so that they don't have to be continuously
recomputed.
-However, a decisive upside of building our own block explorers is that Obscuro's rules about data visibility mean that
+However, a decisive upside of building our own block explorers is that Ten's rules about data visibility mean that
an off-the-shelf block explorer is unlikely to be fit for purpose in various ways, and will require extensive
customisation. We talk about that in section `Fork an existing block explorer for the public block explorer`, below.
@@ -75,12 +75,12 @@ 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 Obscuro chain is returned in an encrypted form. For
- example, if vanilla BlockScout is connected to an Obscuro host, it correctly displays the number of Obscuro 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
- process the chain to allow a given address to see its entire holdings of various tokens. In Obscuro, this processing
+ process the chain to allow a given address to see its entire holdings of various tokens. In Ten, this processing
would have to happen inside the enclave, since the block explorer would not have access to the transaction contents.
Since BlockScout is not written with this in mind, it would entail a large amount of custom code. This is especially
true since the logical place to do this sensitive processing is inside the enclave, but BlockScout is not written in
@@ -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 Obscuro 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 beeb00ffc9..7ca73efd36 100644
--- a/design/ux/user_data_incentives.md
+++ b/design/ux/user_data_incentives.md
@@ -1,4 +1,4 @@
-# User interaction with Obscuro
+# 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.
-Obscuro 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 Obscuro protocol is designed in such a way that it decouples the income from the costs by maintaing a buffer.
+The Ten protocol is designed in such a way that it decouples the income from the costs by maintaing 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 4d4727c0e0..7116f7074a 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 Obscuro 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 Obscuro 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 Obscuro enclave via the Obscuro host over RPC
-* The Obscuro enclave checks the signature
-* The Obscuro 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 Obscuro enclave public key before
- forwarding it to the Obscuro 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 Obscuro 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?
@@ -108,7 +108,7 @@ How do we determine which address is associated with a given request?
### Handling `eth_call` requests
Certain tools (e.g. MetaMask) do not set the `from` field in `eth_call` requests, since this field is marked as
-optional in the Ethereum standard. However, this is problematic for Obscuro, since we need to use this field to
+optional in the Ethereum standard. However, this is problematic for Ten, since we need to use this field to
determine which viewing public key to use to encrypt the response.
We therefore attempt to set any missing `from` fields in `eth_call` requests programmatically, as follows:
@@ -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 Obscuro
+* 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 af4c645d4b..731ab660bd 100644
--- a/developer_onboarding_guide.md
+++ b/developer_onboarding_guide.md
@@ -46,10 +46,10 @@ If you're making substantial changes that could affect E2E tests, you can manual
To do so, follow these steps:
-- Go to the [obscuro-test](https://github.com/obscuronet/obscuro-test/actions) repository
-- Click on the `Run local tests` [link](https://github.com/obscuronet/obscuro-test/actions/workflows/run_local_tests.yml)
+- Go to the [ten-test](https://github.com/ten-protocol/ten-test/actions) repository
+- 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`
-## Obscuro smart contracts
+## Ten smart contracts
-Documentation for Obscuro smart contracts is available [here](https://github.com/obscuronet/go-obscuro/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 f2da0416e0..15714d604b 100644
--- a/dockerfiles/README.md
+++ b/dockerfiles/README.md
@@ -1,6 +1,6 @@
-# Obscuro enclave service Docker image
+# Ten enclave service Docker image
-The Docker image defined by `enclave.Dockerfile` creates a Docker image for an Obscuro 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,18 +12,18 @@ 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 Obscuro 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 Obscuro docker containers:
+Stop and remove all Ten docker containers:
docker rm $(docker stop $(docker ps -a -q --filter ancestor=enclave --format="{{.ID}}"))
## Data directory
-The ego docker images setup a home directory in `/home/obscuro/` and within that `go-obscuro/` contains the code
+The ego docker images setup a home directory in `/home/ten/` and within that `go-ten/` contains the code
while `data/` is used for persistence by the enclave.
-That `/home/obscuro/data` directory is mounted inside the enclave as `/data`, any files written to it by the enclave process
+That `/home/ten/data` directory is mounted inside the enclave as `/data`, any files written to it by the enclave process
should be sealed using the private enclave key, so it will be unreadable to anyone that accesses the container.
\ No newline at end of file
diff --git a/docs/README.md b/docs/README.md
index 107f3b6b58..28fd17c6e3 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -1,17 +1,17 @@
-# Obscuro Doc Site
+# Ten Doc Site
-This is the Obscuro Doc Site and it looks like [this](https://docs.obscu.ro/).
+This is the Ten Doc Site and it looks like [this](https://docs.obscu.ro/).
## Adding New Doc Site Pages
-1. Clone this repository: https://github.com/obscuronet/go-obscuro
+1. Clone this repository: https://github.com/ten-protocol/go-ten
2. Create your new content as a Markdown file in the `/docs` folder of the repo. Take care with the folder structure.
As a general rule, new titles in the left hand navigation menu should have their content contained in a seperate
subfolder under docs, for example, `/docs/testnet` contains all the Markdown files relation to the testnet docs.
3. To have this new content shown in the left-hand navigation menu you need to modify the file
`/docs/_data/navigation.yml`. Follow the same format to add new headings and content titles. Remember to specify the
file type as `.html` for your new Markdown files, not `.md` when providing the URL.
-4. Push your changes to obscuronet/go-obscuro
+4. Push your changes to tennet/go-ten
5. GitHub Pages will trigger a GitHub Action to use a Jekyll build job to create the static content and then publish
the pages at the custom URL.
6. Browse to https://docs.obscu.ro/ and check your content. Remember your browser will cache some of the pages so hit
diff --git a/docs/_docs/api/apis.md b/docs/_docs/api/apis.md
index bdddb7868f..228b44321b 100644
--- a/docs/_docs/api/apis.md
+++ b/docs/_docs/api/apis.md
@@ -1,13 +1,13 @@
---
---
-# Obscuro JSON-RPC API
+# Ten JSON-RPC API
-Obscuro supports a subset of Ethereum's [JSON-RPC API](https://ethereum.org/en/developers/docs/apis/json-rpc/). This
+Ten supports a subset of Ethereum's [JSON-RPC API](https://ethereum.org/en/developers/docs/apis/json-rpc/). This
page details which JSON-RPC API methods are supported.
## Supported JSON-RPC API methods
-Obscuro nodes support the following JSON-RPC API methods over both HTTP and websockets:
+Ten nodes support the following JSON-RPC API methods over both HTTP and websockets:
* `eth_blockNumber`
* `eth_call`
diff --git a/docs/_docs/api/debug-apis.md b/docs/_docs/api/debug-apis.md
index 1916c3855e..a925de3b19 100644
--- a/docs/_docs/api/debug-apis.md
+++ b/docs/_docs/api/debug-apis.md
@@ -2,12 +2,12 @@
---
# Debug JSON-RPC API
-Obscuro supports a subset of Geth's [DEBUG JSON-RPC API](https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-debug). This
+Ten supports a subset of Geth's [DEBUG JSON-RPC API](https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-debug). This
page details which Debug JSON-RPC API methods are supported.
## Supported JSON-RPC API methods
-Obscuro nodes support the following JSON-RPC API methods over both HTTP and websockets:
+Ten nodes support the following JSON-RPC API methods over both HTTP and websockets:
* `debug_traceTransaction`
* `debug_eventLogRelevancy`: returns all event logs generated by the transaction Id, together with the relevancy metadata. Intended for developers on dev networks to debug smart contracts. This call is disabled for production networks
diff --git a/docs/_docs/api/sensitive-apis.md b/docs/_docs/api/sensitive-apis.md
index 0432ae6874..b8188a990e 100644
--- a/docs/_docs/api/sensitive-apis.md
+++ b/docs/_docs/api/sensitive-apis.md
@@ -2,7 +2,7 @@
---
# Sensitive APIs
-Obscuro supports a subset of Ethereum's [JSON-RPC API](https://ethereum.org/en/developers/docs/apis/json-rpc/).
+Ten supports a subset of Ethereum's [JSON-RPC API](https://ethereum.org/en/developers/docs/apis/json-rpc/).
Some of these methods deal with sensitive information. For example, the response to an `eth_getBalance` request will
contain the balance of an account. An attacker could intercept this response to discover a user's balance. To avoid
diff --git a/docs/_docs/community/contributions.md b/docs/_docs/community/contributions.md
index 32325330fb..38a49831f0 100644
--- a/docs/_docs/community/contributions.md
+++ b/docs/_docs/community/contributions.md
@@ -1,14 +1,14 @@
---
---
-# Contributing to Obscuro
+# Contributing to Ten
-Obscuro will evolve to be *the* solution for privacy on Ethereum through the strength and dedication of the Obscuro community. Together we'll make Obscuro the most community-driven project in crypto.
+Ten will evolve to be *the* solution for privacy on Ethereum through the strength and dedication of the Ten community. Together we'll make Ten the most community-driven project in crypto.
-As detailed in the [whitepaper](https://whitepaper.obscu.ro), Obscuro is powered by OBX, a native utility token that provides security to the Obscuro network while allowing holders to pay transaction fees.
+As detailed in the [whitepaper](https://whitepaper.obscu.ro), Ten is powered by TEN, a native utility token that provides security to the Ten network while allowing holders to pay transaction fees.
2% of tokens are set aside for early contributors. Each contributor's allocation is a percentage of their total contributions against the entire community contribution.
-For example, suppose you contribute work worth 10 'task points' and the community as a whole contributes 200 'task points'. In that case, you'll be allocated 5% of the contributor tokens or 0.1% of all available OBX tokens. These tokens will be held and distributed to you according to the vesting schedule detailed in the [tokenomics](https://github.com/obscuronet/foundation/blob/main/token-utility-whitepaper.md). Upon vesting, they will be sent to your wallet.
+For example, suppose you contribute work worth 10 'task points' and the community as a whole contributes 200 'task points'. In that case, you'll be allocated 5% of the contributor tokens or 0.1% of all available TEN tokens. These tokens will be held and distributed to you according to the vesting schedule detailed in the [tokenomics](https://github.com/ten-protocol/foundation/blob/main/token-utility-whitepaper.md). Upon vesting, they will be sent to your wallet.
To help manage contributions, we use DeWork. It's a lot like Trello but crypto-native. The DeWork board has a load of suggested tasks. Anyone can add additional tasks and manage the lifecycle through to completion.
Anyone in the community can suggest a task that will benefit the project and community by adding it to the community suggestions group.
diff --git a/docs/_docs/cross-chain/bridge.md b/docs/_docs/cross-chain/bridge.md
index f4a8f17e43..36e62d31d3 100644
--- a/docs/_docs/cross-chain/bridge.md
+++ b/docs/_docs/cross-chain/bridge.md
@@ -1,8 +1,8 @@
---
---
-# The Standard Obscuro Bridge
+# The Standard Ten Bridge
-The standard Obscuro bridge is a trustless and decentralised asset bridge that uses a wrapped token mint and burn pattern. Under the hood it is based on the cross chain messaging protocol and exists entirely as a smart contract without the need of separate runnables or nodes.
+The standard Ten bridge is a trustless and decentralised asset bridge that uses a wrapped token mint and burn pattern. Under the hood it is based on the cross chain messaging protocol and exists entirely as a smart contract without the need of separate runnables or nodes.
## Contract Addresses
@@ -21,24 +21,24 @@ The value received by the bridge contract during the execution of `sendNative` i
## Layer 1 To Layer 2 Specifics
-The `ObscuroBridge.sol` contract is responsible for managing the layer 1 side of the bridge. It's the "bridge to Obscuro".
+The `TenBridge.sol` contract is responsible for managing the layer 1 side of the bridge. It's the "bridge to Ten".
The `EthereumBridge.sol` contract is responsible for managing the layer 2 side of the bridge. It's the "bridge to Ethereum".
In order to bridge tokens over they need to be whitelisted. **Initially only accounts with the admin role can whitelist tokens!** When the protocol has matured this whitelisting functionality will change. If you want your token to be whitelisted, get in touch with us through our discord.
-When an asset is whitelisted, the bridge internally uses the `publishMessage` call on the `MessageBus` contract which is deployed and exposed by the `ManagementContract` on layer 1. In the message that is published the bridge "tells" the other side of it, which resides on layer 2 that a token has been whitelisted. This in turn creates a wrapped version of the token on the other side. This version of the token can only be minted and burned by the layer 2 bridge. Notice that when the bridge "tells" its counter part, the message is not automatically delivered by Obscuro. To automate the process one needs to have a relayer in place that will do it automatically and a system in place that funds the gas costs of said relayer. As the network grows general purpose relayers might pop up. If you are developing or have developed such a relayer, contact us on discord to get it listed.
+When an asset is whitelisted, the bridge internally uses the `publishMessage` call on the `MessageBus` contract which is deployed and exposed by the `ManagementContract` on layer 1. In the message that is published the bridge "tells" the other side of it, which resides on layer 2 that a token has been whitelisted. This in turn creates a wrapped version of the token on the other side. This version of the token can only be minted and burned by the layer 2 bridge. Notice that when the bridge "tells" its counter part, the message is not automatically delivered by Ten. To automate the process one needs to have a relayer in place that will do it automatically and a system in place that funds the gas costs of said relayer. As the network grows general purpose relayers might pop up. If you are developing or have developed such a relayer, contact us on discord to get it listed.
* Minting allows to create fresh funds on the L2 when they get locked on L1.
* Burning allows to destroy supply on L2 in order to release it from the bridge on L1.
-The protocol to bridge assets using `mint`/`burn` is based on the `MessageBus`'s `publishMessage` too. The `ObscuroBridge` tells the layer 2 that it has locked a certain amount of tokens and because of that address Y should receive the same amount of the wrapped token counterpart. This is when `mint` comes into play. On the other hand, the `EthereumBridge` burns tokens when received and tells the L1 that it has in fact done so. This is interpreted by the L1 smart contract as evidence to release locked funds. This message once again needs to be relayed for the process to work, but by a separate L1 relayer.
+The protocol to bridge assets using `mint`/`burn` is based on the `MessageBus`'s `publishMessage` too. The `TenBridge` tells the layer 2 that it has locked a certain amount of tokens and because of that address Y should receive the same amount of the wrapped token counterpart. This is when `mint` comes into play. On the other hand, the `EthereumBridge` burns tokens when received and tells the L1 that it has in fact done so. This is interpreted by the L1 smart contract as evidence to release locked funds. This message once again needs to be relayed for the process to work, but by a separate L1 relayer.
## Security
-The bridge inherits the `CrossChainEnabledObscuro` contract. It provides a modifier `onlyCrossChainSender` that can be attached to public smart contract functions in order to limit them. Normally you can limit a function to be called by `msg.sender`. With this new modifier you can limit a function to be called from the equivalent of `msg.crosschainsender`. In the `ObscuroBridge` we limit the cross chain sender to the remote bridge only like this `onlyCrossChainSender(remoteBridgeAddress)`.
+The bridge inherits the `CrossChainEnabledTen` contract. It provides a modifier `onlyCrossChainSender` that can be attached to public smart contract functions in order to limit them. Normally you can limit a function to be called by `msg.sender`. With this new modifier you can limit a function to be called from the equivalent of `msg.crosschainsender`. In the `TenBridge` we limit the cross chain sender to the remote bridge only like this `onlyCrossChainSender(remoteBridgeAddress)`.
-The bridge initialization phase links the two bridge contracts (ObscuroBridge, EthereumBridge) together. This linking is finalized when both contracts know the remote address on the opposite layer. Using those remote addresses, the bridges limit incoming `receiveAsset` messages to only be callable by the `CrossChainMessenger` contract sitting on the same layer. This `CrossChainMessenger` contract provides the necessary context to the bridge about the sender of the cross chain message. This allows to validate message is coming from the `remoteBridgeAddress`. The sender address is determined inside of `publishMessage` by taking the `msg.sender`. This `msg.sender` is put inside the metadata of each message.
+The bridge initialization phase links the two bridge contracts (TenBridge, EthereumBridge) together. This linking is finalized when both contracts know the remote address on the opposite layer. Using those remote addresses, the bridges limit incoming `receiveAsset` messages to only be callable by the `CrossChainMessenger` contract sitting on the same layer. This `CrossChainMessenger` contract provides the necessary context to the bridge about the sender of the cross chain message. This allows to validate message is coming from the `remoteBridgeAddress`. The sender address is determined inside of `publishMessage` by taking the `msg.sender`. This `msg.sender` is put inside the metadata of each message.
The result of this setup is that `receiveAsset` is only callable by having a valid cross chain message coming from the correct contract. Anything else will get rejected and cause the call to revert.
diff --git a/docs/_docs/cross-chain/core-messaging-layer.md b/docs/_docs/cross-chain/core-messaging-layer.md
index 39c20bbf0f..4e8acd21b7 100644
--- a/docs/_docs/cross-chain/core-messaging-layer.md
+++ b/docs/_docs/cross-chain/core-messaging-layer.md
@@ -1,8 +1,8 @@
---
---
-# Obscuro Cross Chain Messaging
+# Ten Cross Chain Messaging
-Obscuro is equipped with a cross chain messaging protocol that enables sending and receiving messages across layers securely and in an entirely decentralized fashion.
+Ten is equipped with a cross chain messaging protocol that enables sending and receiving messages across layers securely and in an entirely decentralized fashion.
The core contract that provides this functionality is the `MessageBus`. It exists both on L1 and L2. In the L1 you can find it under the management contract whilst on the L2 it is created and managed by the protocol.
@@ -14,7 +14,7 @@ When the message is made available, users can call the `verifyMessageFinalized`
This allows to have a behaviour much like querying questions - **'Has the address 0xAAAA.. received 25WETH tokens on the bridge with address 0XAB0FF?'**. If the bridge on this address has called `publishMessage` saying **'I have received 25 WETH tokens with recipient 0xAAAA.`** the query will return true.
-When messages are published on the Obscuro layer (L2) the transport to L1 is done by the management contract upon rollup submission. Messages delivered however need to wait for the challenge period of the rollup before being considered final. This ensures that rollups along with the messages they carry can be challenged. This is the logical equivalent of challenge period for optimistic rollups.
+When messages are published on the Ten layer (L2) the transport to L1 is done by the management contract upon rollup submission. Messages delivered however need to wait for the challenge period of the rollup before being considered final. This ensures that rollups along with the messages they carry can be challenged. This is the logical equivalent of challenge period for optimistic rollups.
## Advanced capabilities
diff --git a/docs/_docs/testnet/Introduction.md b/docs/_docs/testnet/Introduction.md
index 46dfb5209c..efc0bba8e0 100644
--- a/docs/_docs/testnet/Introduction.md
+++ b/docs/_docs/testnet/Introduction.md
@@ -1,15 +1,15 @@
---
---
-# Introducing Obscuro's first testnet, Evan's Cat
+# Introducing Ten's first testnet, Evan's Cat
This section contains detailed on how to connect, build and deploy on Evan's Cat. Evan's Cat is designed with developers in mind. It provides the latest upgrades and tooling for developers to deploy and test their dApps.
-Evan's Cat can also be used by end users to help test Obscuro and test developer dApps. Evan's Cat does not focus on node operators. Support for node operators will arrive in the next version of testnet.
+Evan's Cat can also be used by end users to help test Ten and test developer dApps. Evan's Cat does not focus on node operators. Support for node operators will arrive in the next version of testnet.
Developers can expect frequent updates which will be communicated [here](https://docs.obscu.ro/testnet/changelog). The trade-off is that in the early days Testnet will have some sharp edges and unexpected surprises. More specifically, whilst Testnet is in its infancy:
-* Obscuro Testnet will crash from time to time, and will frequently be updated with new features.
-* When Obscuro Testnet restarts expect to lose everything.
-* Obscuro Testnet code has not been optimised or audited yet. (Mainnet code will be audited prior to launch.)
+* Ten Testnet will crash from time to time, and will frequently be updated with new features.
+* When Ten Testnet restarts expect to lose everything.
+* Ten Testnet code has not been optimised or audited yet. (Mainnet code will be audited prior to launch.)
* The [Wallet extension](https://docs.obscu.ro/wallet-extension/wallet-extension) is still being improved.
* The decryption key is known by all allowing you to decrypt and view everything. This also allows the wider community to support you in development.
-All Obscuro code is under an open source licence. If you see something you think could be improved or reworked feel free to submit a PR in the [go-obscuro repo](https://github.com/obscuronet/go-obscuro), or to let us know about your suggestion on [Discord](https://discord.com/channels/916052669955727371/945360340613484684).
+All Ten code is under an open source licence. If you see something you think could be improved or reworked feel free to submit a PR in the [go-ten repo](https://github.com/ten-protocol/go-ten), or to let us know about your suggestion on [Discord](https://discord.com/channels/916052669955727371/945360340613484684).
diff --git a/docs/_docs/testnet/changelog.md b/docs/_docs/testnet/changelog.md
index 41936bd86a..ce964ce99b 100644
--- a/docs/_docs/testnet/changelog.md
+++ b/docs/_docs/testnet/changelog.md
@@ -1,6 +1,6 @@
---
---
-# Obscuro Testnet Change Log
+# Ten Testnet Change Log
# Oct 2023-10-26 (v0.19.0)
* A list of the PRs merged in this release is as below;
@@ -689,9 +689,9 @@
* A variety of stability related issues are fixed within this release.
* Inclusion of a health endpoint for system status monitoring.
* It is now possible to run an Obscuroscan against a locally deployed testnet. For more information see
- [building and running a local testnet](https://github.com/obscuronet/go-obscuro/blob/main/README.md#building-and-running-a-local-testnet)
+ [building and running a local testnet](https://github.com/ten-protocol/go-ten/blob/main/README.md#building-and-running-a-local-testnet)
in the project readme.
-* Obscuroscan's GitHub Actions [deploy script](https://github.com/obscuronet/go-obscuro/blob/main/.github/workflows/manual-deploy-obscuroscan.yml) has been modified to run the public Testnet Obscuroscan as an Azure web app. This allows access via HTTPS (TLS), which allows app developers to call the Obscuroscan API from other web apps.
+* Obscuroscan's GitHub Actions [deploy script](https://github.com/ten-protocol/go-ten/blob/main/.github/workflows/manual-deploy-obscuroscan.yml) has been modified to run the public Testnet Obscuroscan as an Azure web app. This allows access via HTTPS (TLS), which allows app developers to call the Obscuroscan API from other web apps.
* A list of the relevant PRs addressed in this release is as below;
* `12a04c40` Checks whether the head rollup is nil (#859)
* `619d39b4` Clarify that blocks are L1 blocks (#858)
@@ -746,9 +746,9 @@
a contract](https://docs.obscu.ro/testnet/deploying-a-smart-contract-programmatically/) has been updated accordingly.
* The ability to start a faucet server against a local testnet deployment is now supported via a docker
container. For more information see the Obscuro
- [readme](https://github.com/obscuronet/go-obscuro#building-and-running-a-local-faucet).
-* Updates to the [Events](https://github.com/obscuronet/go-obscuro/blob/main/design/ux/Events_design.md) design
- inclusion of the [Fast Finality](https://github.com/obscuronet/go-obscuro/blob/main/design/finality_protocol/fast_finality.md) design.
+ [readme](https://github.com/ten-protocol/go-ten#building-and-running-a-local-faucet).
+* Updates to the [Events](https://github.com/ten-protocol/go-ten/blob/main/design/ux/Events_design.md) design
+ inclusion of the [Fast Finality](https://github.com/ten-protocol/go-ten/blob/main/design/finality_protocol/fast_finality.md) design.
* The [Obscuro docs site](https://docs.obscu.ro/) is now searchable.
* Testnet is now officially termed `Evan's Cat`.
@@ -761,7 +761,7 @@
* Event Subscriptions:
* Event subscriptions for logs are now supported via the eth_subscribe and eth_getLogs approaches. This has been
tested using both the ethers and web3js libraries. Note that eth_newFilter is not currently supported. For more
- information see [the events design](https://github.com/obscuronet/go-obscuro/blob/main/design/Events_design.md).
+ information see [the events design](https://github.com/ten-protocol/go-ten/blob/main/design/Events_design.md).
## September 2022-09-22 (v0.4)
* Wallet extension:
@@ -801,7 +801,7 @@
* The node operator can configure the minimum gas price their aggregator will accept on startup.
* Wallet extension
* The wallet extension now supports multiple viewing keys through a single running instance. For more information see
- the [wallet extension design doc](https://github.com/obscuronet/go-obscuro/blob/main/design/ux/wallet_extension.md),
+ the [wallet extension design doc](https://github.com/ten-protocol/go-ten/blob/main/design/ux/wallet_extension.md),
specifically `Handling eth_call requests` for how the required viewing key is selected when multiple keys are
registered.
diff --git a/docs/_docs/testnet/deploying-a-smart-contract-programmatically.md b/docs/_docs/testnet/deploying-a-smart-contract-programmatically.md
index ed426d58b5..36c9a00d69 100644
--- a/docs/_docs/testnet/deploying-a-smart-contract-programmatically.md
+++ b/docs/_docs/testnet/deploying-a-smart-contract-programmatically.md
@@ -1,11 +1,11 @@
---
---
-# Deploying a Smart Contract to Obscuro Testnet Programmatically
-The steps below demonstrate how to programmatically create a new contract on to Obscuro Testnet and interact with it via
+# Deploying a Smart Contract to Ten Testnet Programmatically
+The steps below demonstrate how to programmatically create a new contract on to Ten Testnet and interact with it via
call functions. The example uses [Python](https://www.python.org/) and [web3.py](https://web3py.readthedocs.io/en/stable/)
as a reference but the principles of usage will be the same in any web3 language implementation.
-A full working example can be seen in [deploying-a-smart-contract-programmatically.py](https://github.com/obscuronet/go-obscuro/blob/main/docs/_docs/testnet/deploying-a-smart-contract-programmatically.py).
+A full working example can be seen in [deploying-a-smart-contract-programmatically.py](https://github.com/ten-protocol/go-ten/blob/main/docs/_docs/testnet/deploying-a-smart-contract-programmatically.py).
Usage of the example requires Python > 3.9.13, solc 0.8.15 and the web3, requests, and json modules. It is assumed solc
has been installed using homebrew and resides in `/opt/homebrew/bin/solc` and that the wallet extension is running on
the local host with default values `WHOST=127.0.0.1` and `WPORT=3000`.
@@ -25,7 +25,7 @@ account stored for later usage.
```
## Request ETH from the faucet server for native ETH
-An account needs gas to perform transactions on Obscuro, where gas is paid in native ETH. Requests of native ETH can be
+An account needs gas to perform transactions on Ten, where gas is paid in native ETH. Requests of native ETH can be
made through a POST to the faucet server where the address is supplied in the data payload.
```python
headers = {'Content-Type': 'application/json'}
@@ -68,7 +68,7 @@ release). An arbitrary `gasPrice` should be given e.g. the current price on the
```
## Sign the transaction and send to the network
-Using the account the transaction can be signed and submitted to the Obscuro Testnet.
+Using the account the transaction can be signed and submitted to the Ten Testnet.
```python
signed_tx = account.signTransaction(build_tx)
tx_hash = None
diff --git a/docs/_docs/testnet/deploying-a-smart-contract.md b/docs/_docs/testnet/deploying-a-smart-contract.md
index b8e60171f7..a74c0c532d 100644
--- a/docs/_docs/testnet/deploying-a-smart-contract.md
+++ b/docs/_docs/testnet/deploying-a-smart-contract.md
@@ -1,27 +1,27 @@
---
---
-# Deploying a Smart Contract to Obscuro Testnet
-Using the steps below you will add an extension to your MetaMask wallet so it can connect to Obscuro Testnet, then using Remix you will deploy your smart contract to Testnet. Remember there are no gas fees on Obscuro Testnet so you do not need to load your account with OBX tokens in advance.
+# Deploying a Smart Contract to Ten Testnet
+Using the steps below you will add an extension to your MetaMask wallet so it can connect to Ten Testnet, then using Remix you will deploy your smart contract to Testnet. Remember there are no gas fees on Ten Testnet so you do not need to load your account with TEN tokens in advance.
## Prerequisites
* [MetaMask](https://metamask.io/) wallet installed in your browser.
-* A local copy of the [Obscuro MetaMask wallet extension](https://docs.obscu.ro/wallet-extension/wallet-extension/)
+* A local copy of the [Ten MetaMask wallet extension](https://docs.obscu.ro/wallet-extension/wallet-extension/)
-## Prepare Your MetaMask Wallet for Obscuro Testnet
-An essential part of how Obscuro provides full privacy is the encryption of communication between an Obscuro application and Obscuro nodes on the network.
+## Prepare Your MetaMask Wallet for Ten Testnet
+An essential part of how Ten provides full privacy is the encryption of communication between an Ten application and Ten nodes on the network.
Follow the steps [here](https://docs.obscu.ro/wallet-extension/wallet-extension/) to configure and start the wallet extension and
generate a viewing key.
-If you do not have the Obscuro wallet extension running, MetaMask will not be able to communicate with the Obscuro
+If you do not have the Ten wallet extension running, MetaMask will not be able to communicate with the Ten
Testnet.
> **_TIP_** Every time you restart the wallet extension, you must generate a new viewing key. This is because the
private-key part of the viewing key is only held in memory and never persisted to disk, for security reasons.
-Your wallet is now configured for the Obscuro Testnet which allows you to view encrypted traffic for your wallet only.
-You can now go ahead and deploy your smart contract to the Obscuro Testnet.
+Your wallet is now configured for the Ten Testnet which allows you to view encrypted traffic for your wallet only.
+You can now go ahead and deploy your smart contract to the Ten Testnet.
## Deploy Your Smart Contract Using an IDE
1. Browse to the popular Solidity-compatible Integrated Development Environment called [Remix](https://remix.ethereum.org/).
@@ -32,20 +32,20 @@ You can now go ahead and deploy your smart contract to the Obscuro Testnet.
1. Compile your smart contract using the Remix Solidity Compiler.
-1. Log in to MetaMask and confirm you are connected to Obscuro Testnet network. The parameters for the Obscuro Testnet can be found [here](https://docs.obscu.ro/testnet/essentials/).
+1. Log in to MetaMask and confirm you are connected to Ten Testnet network. The parameters for the Ten Testnet can be found [here](https://docs.obscu.ro/testnet/essentials/).
-1. In the _Deploy & Run Transactions_ section of Remix change the Environment to _Injected Web3_. This tells Remix to use the network settings currently configured in your MetaMask wallet, which in this case is the Obscuro Testnet. If the connection to Obscuro Testnet is successful you will see the text _Custom (443) network_ displayed under _Injected Web3_.
+1. In the _Deploy & Run Transactions_ section of Remix change the Environment to _Injected Web3_. This tells Remix to use the network settings currently configured in your MetaMask wallet, which in this case is the Ten Testnet. If the connection to Ten Testnet is successful you will see the text _Custom (443) network_ displayed under _Injected Web3_.
-1. Click the _Deploy_ button to deploy your smart contract to the Obscuro Testnet.
+1. Click the _Deploy_ button to deploy your smart contract to the Ten Testnet.
1. MetaMask will automatically open and ask you to confirm the transaction. Click _Confirm_.
1. Wait for your transaction to be confirmed. Notifications will be shown in MetaMask and Remix to indicate that the transaction was successful.
-Congratulations, your smart contract is now deployed to Obscuro Testnet!
+Congratulations, your smart contract is now deployed to Ten Testnet!
-> **Be prepared to redeploy your smart contract to Obscuro Testnet often. The Testnet is likely to be restarted without warning!** As Testnet matures and new features are added it will become more and more stable, but in the early days do expect some turbulence.
+> **Be prepared to redeploy your smart contract to Ten Testnet often. The Testnet is likely to be restarted without warning!** As Testnet matures and new features are added it will become more and more stable, but in the early days do expect some turbulence.
-Because Obscuro provides full privacy, the details of your transaction are encrypted and only visible to you, as the holder of your wallet's private key.
+Because Ten provides full privacy, the details of your transaction are encrypted and only visible to you, as the holder of your wallet's private key.
-Now head over to the [ObscuroScan page](https://docs.obscu.ro/testnet/obscuroscan/) to see how you can view the transaction details.
+Now head over to the [TenScan page](https://docs.obscu.ro/testnet/obscuroscan/) to see how you can view the transaction details.
diff --git a/docs/_docs/testnet/essentials.md b/docs/_docs/testnet/essentials.md
index cbfba40dfc..20b2f2d18e 100644
--- a/docs/_docs/testnet/essentials.md
+++ b/docs/_docs/testnet/essentials.md
@@ -6,19 +6,19 @@ Essential information, parameters and configuration settings for the Evan's Cat
## Limitations on Evan's Cat
These are the key limitations to be aware of when developing for the Evan's Cat testnet:
-1. New nodes cannot be added. For now the number of Obscuro nodes is fixed.
+1. New nodes cannot be added. For now the number of Ten nodes is fixed.
1. Data revelation is not implemented yet.
1. Security is not fully implemented. Some keys are still hardcoded.
1. The decentralised bridge is limited to two hardcoded ERC20 tokens.
-1. The Layer 1 is currently a hosted network. In the next iteration we'll connect Obscuro to an Ethereum testnet.
-1. The "Wallet Extension" is not fully polished yet. You can expect a better UX as Obscuro develops
+1. The Layer 1 is currently a hosted network. In the next iteration we'll connect Ten to an Ethereum testnet.
+1. The "Wallet Extension" is not fully polished yet. You can expect a better UX as Ten develops
-## Connection to an Obscuro Node
+## Connection to an Ten Node
- **RPC http address:** `erpc.sepolia-testnet.obscu.ro:80`
- **RPC websocket address:** `erpc.sepolia-testnet.obscu.ro:81`
## Rollup Encryption/Decryption Key
-The symmetric key used to encrypt and decrypt transaction blobs in rollups on the Obscuro Testnet:
+The symmetric key used to encrypt and decrypt transaction blobs in rollups on the Ten Testnet:
```
bddbc0d46a0666ce57a466168d99c1830b0c65e052d77188f2cbfc3f6486588c
@@ -26,7 +26,7 @@ bddbc0d46a0666ce57a466168d99c1830b0c65e052d77188f2cbfc3f6486588c
N.B. Decrypting transaction blobs is only possible on testnet, where the rollup encryption key is long-lived and
well-known. On mainnet, rollups will use rotating keys that are not known to anyone - or anything - other than the
-Obscuro enclaves.
+Ten enclaves.
## ERC20 Contracts
We have a couple of testnet ERC20 tokens (HOC & POC) that are automatically deployed with a static address every time
diff --git a/docs/_docs/testnet/example-dapps.md b/docs/_docs/testnet/example-dapps.md
index 5fcadaaf34..ea375db34c 100644
--- a/docs/_docs/testnet/example-dapps.md
+++ b/docs/_docs/testnet/example-dapps.md
@@ -1,20 +1,20 @@
---
---
# Example dApps on Testnet
-Obscuro Testnet includes an example dApp to help you better understand how dApps capitalise on Obscuro's unique encryption features.
+Ten Testnet includes an example dApp to help you better understand how dApps capitalise on Ten's unique encryption features.
## Number Guessing Game
-[A number guessing game](http://obscuronet.github.io/sample-applications/number-guessing-game) is a simple way of showcasing the principles of encryption in Obscuro. The goal of the game is to guess a secret number. Each time an attempt is made an entrance fee of 1 unit of the token is paid (with 1x10^18 units making a single token). If a player correctly guesses the number the contract will pay out all of the accumulated entrance fees to them and reset itself with a new random number.
+[A number guessing game](http://tennet.github.io/sample-applications/number-guessing-game) is a simple way of showcasing the principles of encryption in Ten. The goal of the game is to guess a secret number. Each time an attempt is made an entrance fee of 1 unit of the token is paid (with 1x10^18 units making a single token). If a player correctly guesses the number the contract will pay out all of the accumulated entrance fees to them and reset itself with a new random number.
Consider for a moment how a secret number could be created without divulging it. This is impossible in a transparent, decentralised ecosystem like Ethereum because when the secret number is generated by the smart contract it would be trivial to look up the internal state of the contract and see the secret number. OK, so let's imagine the internal state of the contract and therefore the secret number _is_ hidden, what happens when players start making their guesses? Using a block explorer to see the attempted guesses in plain view within the details of the transaction immediately provides new players with an unfair advantage and the game is ruined.
-Building the guessing game in Obscuro addresses both scenarios described above. The guessing game smart contract generates a random secret number when it is deployed. This number is never revealed to a player or node operator, or indeed anybody because it is generated within a Trusted Execution Environment. And when players make their guesses the transactions carrying the guesses are encrypted and therefore obscured in a block explorer.
+Building the guessing game in Ten addresses both scenarios described above. The guessing game smart contract generates a random secret number when it is deployed. This number is never revealed to a player or node operator, or indeed anybody because it is generated within a Trusted Execution Environment. And when players make their guesses the transactions carrying the guesses are encrypted and therefore obscured in a block explorer.
### How to Play
1. Start up the wallet extension. Follow instructions [here](https://docs.obscu.ro/wallet-extension/wallet-extension).
-1. For the moment, the Guessing Game includes an ERC20 token (called OGG, short for Obscuro Guessing Game). This is partly because OGG is modified to have a built-in faucet: It allocates tokens to addresses as they make a request to allow other addresses to take tokens from their account.
+1. For the moment, the Guessing Game includes an ERC20 token (called OGG, short for Ten Guessing Game). This is partly because OGG is modified to have a built-in faucet: It allocates tokens to addresses as they make a request to allow other addresses to take tokens from their account.
1. If you want to see this balance in your wallet, you have to import a new Token with the address: ``0x5FbDB2315678afecb367f032d93F642f64180aa3``
-1. Browse to [the number guessing game](http://obscuronet.github.io/sample-applications/number-guessing-game). Check you see `Network ID: 443` at the top of the game window to confirm you are connected to Obscuro Testnet.
+1. Browse to [the number guessing game](http://tennet.github.io/sample-applications/number-guessing-game). Check you see `Network ID: 443` at the top of the game window to confirm you are connected to Ten Testnet.
1. MetaMask will open and ask to connect your account. Click `Next` then click `Connect`.
1. Approve the payment of 1 or more token units to play the game (this will be added to the prize pool) by clicking the `Approve game fee` button.
1. MetaMask will ask for your account to sign a transaction specifying the Guess contract address as the approval delegate. This means that you're giving permission for the game to take the participation fee. Click `Confirm`. Once approved you will see a confirmation popup. Click `OK`.
@@ -23,8 +23,8 @@ Building the guessing game in Obscuro addresses both scenarios described above.
1. Open MetaMask to check the progress of your guess transaction in the `Activity` tab of MetaMask. Wait a few moments for it to change from pending to complete.
1. The game should show you two messages, one confirming the success of the Approval transaction, and the second confirming the result of the guess attempt (whether correct, wrong, warmer or colder than the last guess).
-Once the guess transaction is completed you can check the guess transaction on ObscuroScan:
-1. In MetaMask click on the transaction to open it then click `Copy Transaction ID`. Open [ObscuroScan](http://testnet.obscuroscan.io/).
+Once the guess transaction is completed you can check the guess transaction on TenScan:
+1. In MetaMask click on the transaction to open it then click `Copy Transaction ID`. Open [TenScan](http://testnet.tenscan.io/).
1. Paste your copied transaction ID into the search box to find your individual guess transaction. Note how the transaction data visible to everyone is encrypted in the field `EncryptedTxBlob` and how (for now) the transaction is decrypted to allow developers to confirm correct behaviour of the network.
1. You can see your guess as the number at the right hand end of the `input` value in a hexadecimal format, e.g. a guess of 99 is shown as 63.
@@ -35,5 +35,5 @@ Once the guess transaction is completed you can check the guess transaction on O
### Next Steps
-Now you have enjoyed playing the guessing game you are invited to make it even better! Go ahead and fork the guessing game code in this [GitHub repository](https://github.com/obscuronet/number-guessing-game) and bring your own contributions to Obscuro Testnet.
+Now you have enjoyed playing the guessing game you are invited to make it even better! Go ahead and fork the guessing game code in this [GitHub repository](https://github.com/ten-protocol/number-guessing-game) and bring your own contributions to Ten Testnet.
Of course, you are free to [deploy any smart contract](https://docs.obscu.ro/testnet/deploying-a-smart-contract) to the testnet.
diff --git a/docs/_docs/testnet/faucet.md b/docs/_docs/testnet/faucet.md
index 0ca27e478d..53777a402c 100644
--- a/docs/_docs/testnet/faucet.md
+++ b/docs/_docs/testnet/faucet.md
@@ -1,16 +1,16 @@
---
---
# Using the Testnet Token Faucet
-Using the steps below you will request testnet ETH from the faucet available on the Obscuro Discord server.
+Using the steps below you will request testnet ETH from the faucet available on the Ten Discord server.
## Prerequisites
-* Access to the [Obscuro Discord server](https://discord.gg/yQfmKeNzNd).
+* Access to the [Ten Discord server](https://discord.gg/yQfmKeNzNd).
* (Optional) [MetaMask](https://metamask.io/) wallet installed in your browser.
-* (Optional) A local copy of the [Obscuro MetaMask wallet extension](https://docs.obscu.ro/wallet-extension/wallet-extension/).
+* (Optional) A local copy of the [Ten MetaMask wallet extension](https://docs.obscu.ro/wallet-extension/wallet-extension/).
## Requesting Testnet ETH
1. Make a note of your wallet address or copy it to your clipboard.
-2. Open the [_faucet-requests_ channel](https://discord.gg/5qyj3qraaH) on Obscuro Discord.
+2. Open the [_faucet-requests_ channel](https://discord.gg/5qyj3qraaH) on Ten Discord.
3. Request ETH using the `/faucet` command. The faucet will credit 0.5 ETH by default:
![faucet command](../../assets/images/faucet-cmd.png)
4. Provide your wallet address and hit Enter. The faucet will acknowledge your request:
@@ -19,9 +19,9 @@ Using the steps below you will request testnet ETH from the faucet available on
![faucet complete](../../assets/images/faucet-done.png)
## Viewing Your Wallet Balance
-To view the balance of your wallet you will need to establish a connection from your wallet to the Obscuro Testnet. An essential part of how Obscuro provides full privacy is the encryption of communication between an Obscuro application and Obscuro nodes on the network. As a result, you will need to use the wallet extension to allow your wallet to communication with the Obscuro Testnet.
+To view the balance of your wallet you will need to establish a connection from your wallet to the Ten Testnet. An essential part of how Ten provides full privacy is the encryption of communication between an Ten application and Ten nodes on the network. As a result, you will need to use the wallet extension to allow your wallet to communication with the Ten Testnet.
-Use the steps [here](https://docs.obscu.ro/testnet/deploying-a-smart-contract/#prepare-your-metamask-wallet-for-obscuro-testnet) to prepare your MetaMask wallet for Obscuro Testnet.
+Use the steps [here](https://docs.obscu.ro/testnet/deploying-a-smart-contract/#prepare-your-metamask-wallet-for-ten-testnet) to prepare your MetaMask wallet for Ten Testnet.
## Requesting Testnet ETH directly
In the event that you do not have access to Discord, or the faucet bot is not working, you can request ETH directly from
diff --git a/docs/_docs/testnet/obscuroscan.md b/docs/_docs/testnet/obscuroscan.md
index 2b66538ecd..d65ab5b026 100644
--- a/docs/_docs/testnet/obscuroscan.md
+++ b/docs/_docs/testnet/obscuroscan.md
@@ -1,13 +1,13 @@
---
---
-# ObscuroScan
-ObscuroScan is a blockchain explorer for the Obscuro Testnet -
-Obscuro's equivalent of Etherscan. ObscuroScan allows you to view the latest rollups and transactions on the Testnet,
+# TenScan
+TenScan is a blockchain explorer for the Ten Testnet -
+Ten's equivalent of Etherscan. TenScan allows you to view the latest rollups and transactions on the Testnet,
as well as search for historical rollups and transactions. Its functionality will be expanded over time.
## Usage
-1. Go to the [ObscuroScan landing page](http://testnet.obscuroscan.io/)
+1. Go to the [TenScan landing page](http://testnet.tenscan.io/)
2. Observe the feed of latest rollups and transactions. Click on any rollup number or transaction hash to see the
details of the corresponding rollup and the L1 block where it was published
3. From the search bar in the top right, search for any rollup (using its number, e.g. `2453`) or transaction (using
@@ -16,6 +16,6 @@ as well as search for historical rollups and transactions. Its functionality wil
## Decryption of Transaction Blobs
Notice the _Decrypted transaction blob_ section for each rollup. This allows you to see the normally-encrypted
-transactions in unencrypted plain text. This is a feature of Testnet aimed at helping you understand how Obscuro works,
+transactions in unencrypted plain text. This is a feature of Testnet aimed at helping you understand how Ten works,
and is only possible because Testnet uses a rollup encryption key that is long-lived and well-known. On Mainnet,
-rollups will be encrypted with rotating keys that are not known to anyone, or anything, other than the Obscuro enclaves.
+rollups will be encrypted with rotating keys that are not known to anyone, or anything, other than the Ten enclaves.
diff --git a/docs/_docs/testnet/security.md b/docs/_docs/testnet/security.md
index 530b22b6a6..fe2d6e4e27 100644
--- a/docs/_docs/testnet/security.md
+++ b/docs/_docs/testnet/security.md
@@ -2,9 +2,9 @@
---
# Testnet Security
-The first Obscuro Testnet is focused on functionality and the User and Developer experience.
+The first Ten Testnet is focused on functionality and the User and Developer experience.
Privacy features require special attention from the core and security audit team and will be finalised in a
future version of Testnet.
-As a user of the "Obscuro Testnet", do not expect the data you are loading to be 100% private.
+As a user of the "Ten Testnet", do not expect the data you are loading to be 100% private.
diff --git a/docs/_docs/testnet/starting-a-node.md b/docs/_docs/testnet/starting-a-node.md
index 3fd27251de..214088d870 100644
--- a/docs/_docs/testnet/starting-a-node.md
+++ b/docs/_docs/testnet/starting-a-node.md
@@ -19,25 +19,25 @@ sudo apt-get update \
&& sudo snap refresh && sudo snap install --channel=1.20 go --classic
```
-#### - Download Obscuro repo
+#### - Download Ten repo
-Make sure to use the latest `` at https://github.com/obscuronet/go-obscuro/tags.
+Make sure to use the latest `` at https://github.com/ten-protocol/go-ten/tags.
```
- git clone --depth 1 -b https://github.com/obscuronet/go-obscuro.git /home/obscuro/go-obscuro
+ git clone --depth 1 -b https://github.com/ten-protocol/go-ten.git /home/ten/go-ten
```
-#### - Start Obscuro Node
+#### - Start Ten Node
-To start the obscuro node some information is required to populate the starting script.
+To start the ten node some information is required to populate the starting script.
- (host_public_p2p_addr) The external facing address of the network. Where outside peers will connect to. Must be open to outside connections.`curl https://ipinfo.io/ip` provides the external IP.
- (private_key) Private Key to issue transactions into the Layer 1
- (host_id) Public Key derived from the Private Key
```
-go run /home/obscuro/go-obscuro/go/node/cmd \
+go run /home/ten/go-ten/go/node/cmd \
-is_genesis="false" \
-node_type=validator \
-is_sgx_enabled="true" \
diff --git a/docs/_docs/testnet/tutorial.md b/docs/_docs/testnet/tutorial.md
index c2d7120096..02a354bc0e 100644
--- a/docs/_docs/testnet/tutorial.md
+++ b/docs/_docs/testnet/tutorial.md
@@ -1,21 +1,21 @@
---
---
# Getting Started
-In this tutorial, you build your own Obscuro dApp from the start. This is an excellent way to experience a typical development process as you learn how Obscuro dApps are built, design concepts, tools and terminology.
+In this tutorial, you build your own Ten dApp from the start. This is an excellent way to experience a typical development process as you learn how Ten dApps are built, design concepts, tools and terminology.
# Let's go
-In this tutorial, we'll build a 'Guessing Game' dApp that provides an introduction to the fundamentals of Obscuro and shows you how to:
-- Set up your local Ethereum development environment for Obscuro.
-- Use Obscuro concepts to develop a dApp.
+In this tutorial, we'll build a 'Guessing Game' dApp that provides an introduction to the fundamentals of Ten and shows you how to:
+- Set up your local Ethereum development environment for Ten.
+- Use Ten concepts to develop a dApp.
What is the *Guessing Game*?
-The Guessing Game is an example of a dApp that can only be built on Obscuro, and not on native Ethereum.
+The Guessing Game is an example of a dApp that can only be built on Ten, and not on native Ethereum.
-You will build a dApp that demonstrates a basic Obscuro use case, a simple number guessing game. The dApp's smart contract generates a random secret number, which is never revealed to anyone, including node operators, developers or end-user because of the privacy provided by Obscuro. The goal of the game is to guess this number, and each time an attempt is made, an entrance fee of 1 token is paid. If a user correctly guesses the number, the contract will pay out all of the accumulated entrance fees to them and reset itself with a new random number.
+You will build a dApp that demonstrates a basic Ten use case, a simple number guessing game. The dApp's smart contract generates a random secret number, which is never revealed to anyone, including node operators, developers or end-user because of the privacy provided by Ten. The goal of the game is to guess this number, and each time an attempt is made, an entrance fee of 1 token is paid. If a user correctly guesses the number, the contract will pay out all of the accumulated entrance fees to them and reset itself with a new random number.
-Without Obscuro, it would be possible to look up the internal state of the contract and cheat, and the game wouldn't work.
+Without Ten, it would be possible to look up the internal state of the contract and cheat, and the game wouldn't work.
The dApp has many of the features that you'd expect to find, including:
- Generating a random number known only to the dApp.
@@ -27,11 +27,11 @@ The dApp has many of the features that you'd expect to find, including:
# Set up your environment
- You'll need to install MetaMask following the instructions [here](https://metamask.io/)
-- Then download and run the Obscuro Wallet extension following the instructions [here](https://docs.obscu.ro/wallet-extension/wallet-extension)
-- Now connect MetaMask to the Obscuro testnet following the instructions [here](https://docs.obscu.ro/wallet-extension/configure-metamask)
+- Then download and run the Ten Wallet extension following the instructions [here](https://docs.obscu.ro/wallet-extension/wallet-extension)
+- Now connect MetaMask to the Ten testnet following the instructions [here](https://docs.obscu.ro/wallet-extension/configure-metamask)
- Finally, check you can open the Remix IDE by visiting the following URL in your browser https://remix.ethereum.org
-That's it. You're all set to start building your first dApp on Obscuro.
+That's it. You're all set to start building your first dApp on Ten.
## 1. To begin, we'll clone a template smart contract from Github through Remix by following these instructions
@@ -39,7 +39,7 @@ That's it. You're all set to start building your first dApp on Obscuro.
![Step 1 screenshot](https://images.tango.us/workflows/57863807-6b96-4295-a7a1-42da1623f030/steps/919b227f-f1f5-4af3-aba1-7fb83576d505/8144f3f5-7855-4c83-86dd-c88e5476c367.png?crop=focalpoint&fit=crop&fp-x=0.5000&fp-y=0.5000&fp-z=1.0000&w=1200&mark-w=0.2&mark-pad=0&mark64=aHR0cHM6Ly9pbWFnZXMudGFuZ28udXMvc3RhdGljL21hZGUtd2l0aC10YW5nby13YXRlcm1hcmsucG5n&ar=874%3A594)
-#### Paste "https://github.com/obscuronet/tutorial/blob/main/number-guessing-game/contracts/Guess.sol" into input
+#### Paste "https://github.com/ten-protocol/tutorial/blob/main/number-guessing-game/contracts/Guess.sol" into input
![Step 2 screenshot](https://images.tango.us/workflows/57863807-6b96-4295-a7a1-42da1623f030/steps/4b3b212d-2518-4cc9-aab2-4befe128b38c/66a9a87d-0899-42d2-8f6a-98f204b25825.png?crop=focalpoint&fit=crop&fp-x=0.5000&fp-y=0.5000&fp-z=1.0000&w=1200&mark-w=0.2&mark-pad=0&mark64=aHR0cHM6Ly9pbWFnZXMudGFuZ28udXMvc3RhdGljL21hZGUtd2l0aC10YW5nby13YXRlcm1hcmsucG5n&ar=530%3A371)
@@ -48,7 +48,7 @@ That's it. You're all set to start building your first dApp on Obscuro.
# Let's code
-Guess.sol is a Solidity file, and once we're done, it will contain everything we need for the Guessing Game. Inside the file you'll find the classic ERC-20 interface and a simple implementation named ERC20Basic representing OGG (Obscuro Guessing Game token). We'll use OGG as a means of entry to play and to generate the prize pool.
+Guess.sol is a Solidity file, and once we're done, it will contain everything we need for the Guessing Game. Inside the file you'll find the classic ERC-20 interface and a simple implementation named ERC20Basic representing OGG (Ten Guessing Game token). We'll use OGG as a means of entry to play and to generate the prize pool.
There is also a skeleton contract called Guess inside Guess.sol, and this is what we'll be extending. The contract Guess will be written the same as any other Solidity contract in Ethereum. It'll run on the EVM and will exhibit the same behaviours.
@@ -60,7 +60,7 @@ Let's start by defining the key variables we'll need for the game. One is to sto
uint8 private _target
IERC20 public erc20
```
-Upon seeing this, you might think, hang on, I can see *_target* is set to private, but so what? Private variables in Ethereum don't really mean they're private, just that they can't be accessed or modified by other smart contracts. And you're right, that's the case in Ethereum. But in Obscuro, private variables *really* are private (unless you explicitly decide to reveal them!). This is because all contracts and contract data is encrypted and only accessible within enclaves.
+Upon seeing this, you might think, hang on, I can see *_target* is set to private, but so what? Private variables in Ethereum don't really mean they're private, just that they can't be accessed or modified by other smart contracts. And you're right, that's the case in Ethereum. But in Ten, private variables *really* are private (unless you explicitly decide to reveal them!). This is because all contracts and contract data is encrypted and only accessible within enclaves.
Our variables should now look like this
![Step 1 screenshot](https://images.tango.us/workflows/dc61d575-7eea-457c-bdfe-8edccf79b366/steps/3d9b387b-a492-4096-aa8a-1d50084be0d5/6d08adce-70d2-4203-8d18-c09999536553.png?crop=focalpoint&fit=crop&fp-x=0.5000&fp-y=0.5000&fp-z=1.0000&w=1200&mark-w=0.2&mark-pad=0&mark64=aHR0cHM6Ly9pbWFnZXMudGFuZ28udXMvc3RhdGljL21hZGUtd2l0aC10YW5nby13YXRlcm1hcmsucG5n&ar=413%3A131)
@@ -128,13 +128,13 @@ If it's not correct, we do nothing. For example, your code might look something
![Step 1 screenshot](https://images.tango.us/workflows/7073e589-7d79-491f-b4f1-27db2eb144c1/steps/ad4b9d9a-5793-420f-b21c-3a22ae8e83b5/b016b98e-203a-4362-9c14-6ff2928b9ba8.png?crop=focalpoint&fit=crop&fp-x=0.5000&fp-y=0.5000&fp-z=1.0000&w=1200&mark-w=0.2&mark-pad=0&mark64=aHR0cHM6Ly9pbWFnZXMudGFuZ28udXMvc3RhdGljL21hZGUtd2l0aC10YW5nby13YXRlcm1hcmsucG5n&ar=879%3A246)
-This works. You now have an Obscuro contract that will let players play the guessing game. But it's not very good. So how do players know if they've won or not? We need events!
+This works. You now have an Ten contract that will let players play the guessing game. But it's not very good. So how do players know if they've won or not? We need events!
-In Ethereum, events are typically written to the event log that is viewable by everyone. In Obscuro, events are viewable only to those they're intended for. This is done by encrypting events with a key that is known only to the intended recipient. This is handled automatically for the recipient through the Wallet Extension.
+In Ethereum, events are typically written to the event log that is viewable by everyone. In Ten, events are viewable only to those they're intended for. This is done by encrypting events with a key that is known only to the intended recipient. This is handled automatically for the recipient through the Wallet Extension.
So let's go ahead and start adding in some events. First, we'll need to emit events letting a player know after they've played whether they have won or not.
-Events in Obscuro look exactly like events in any other EVM-based platform. All the complexity of ensuring privacy is abstracted away. So let's go ahead and define two new events in our contract.
+Events in Ten look exactly like events in any other EVM-based platform. All the complexity of ensuring privacy is abstracted away. So let's go ahead and define two new events in our contract.
```
event Correct(address indexed player, uint8 guess, uint prize);
@@ -154,7 +154,7 @@ Our function to return the prize pool is:
![Step 1 screenshot](https://images.tango.us/workflows/74ec7481-8c33-401f-8476-07c777e7cd3d/steps/d4a753b9-f507-4f6c-b080-40587ec82c00/8ffdc581-6e95-40bb-9c11-d3fa0ef01d84.png?crop=focalpoint&fit=crop&fp-x=0.5000&fp-y=0.5000&fp-z=1.0000&w=1200&mark-w=0.2&mark-pad=0&mark64=aHR0cHM6Ly9pbWFnZXMudGFuZ28udXMvc3RhdGljL21hZGUtd2l0aC10YW5nby13YXRlcm1hcmsucG5n&ar=518%3A87)
-And that's it! Congratulations on writing your first Obscuro smart contract!
+And that's it! Congratulations on writing your first Ten smart contract!
You can now go ahead and deploy the contract following the instructions [here](https://docs.obscu.ro/testnet/deploying-a-smart-contract)
diff --git a/docs/_docs/wallet-extension/configure-metamask.md b/docs/_docs/wallet-extension/configure-metamask.md
index 709612741a..b01a98d8d6 100644
--- a/docs/_docs/wallet-extension/configure-metamask.md
+++ b/docs/_docs/wallet-extension/configure-metamask.md
@@ -2,9 +2,9 @@
---
# Configuring MetaMask
-To keep data encrypted between MetaMask and the Obscuro network, MetaMask needs to be configured to point to the local Wallet Extension as follows:
+To keep data encrypted between MetaMask and the Ten network, MetaMask needs to be configured to point to the local Wallet Extension as follows:
-* Network Name: Obscuro Testnet
+* Network Name: Ten Testnet
* New RPC URL: `http://127.0.0.1:3000/`
* Chain ID: 443
* Currency Symbol: ETH
diff --git a/docs/_docs/wallet-extension/wallet-extension.md b/docs/_docs/wallet-extension/wallet-extension.md
index 439a018c32..1af5ce0ae9 100644
--- a/docs/_docs/wallet-extension/wallet-extension.md
+++ b/docs/_docs/wallet-extension/wallet-extension.md
@@ -1,16 +1,16 @@
---
---
-# The Obscuro Wallet Extension
+# The Ten Wallet Extension
-The wallet extension is the Obscuro component that ensures that sensitive information in RPC requests between client
-applications and the Obscuro enclave, such as balances or transactions, cannot be seen by third parties. It
-achieves this goal without requiring any custom wallet software or application code changes. Private keys for Obscuro
+The wallet extension is the Ten component that ensures that sensitive information in RPC requests between client
+applications and the Ten enclave, such as balances or transactions, cannot be seen by third parties. It
+achieves this goal without requiring any custom wallet software or application code changes. Private keys for Ten
addresses may be stored in [MetaMask](https://metamask.io/), for example, and the Wallet Extension will act as a bridge
-between MetaMask and an Obscuro host without ever knowing your wallet's private keys itself.
+between MetaMask and an Ten host without ever knowing your wallet's private keys itself.
The wallet extension performs two functions:
-* Encrypting outgoing RPC requests using the public key of the Obscuro enclave.
+* Encrypting outgoing RPC requests using the public key of the Ten enclave.
* Decrypting incoming RPC responses for [privacy-sensitive requests](https://docs.obscu.ro/api/sensitive-apis/) (e.g. `eth_getBalance`,
`eth_call` and `eth_getTransactionReceipt`) using an address-specific _viewing key_.
@@ -22,7 +22,7 @@ to securely decrypt the incoming messages.
The wallet extension should be run locally by the user, such that no sensitive data leaves the client's machine
unencrypted. If the data is not particularly sensitive, it can also be run in another trusted location.
-This diagram shows how Wallet Extension fits into the Obscuro workflow as a bridge between standard ethereum ecosystem
+This diagram shows how Wallet Extension fits into the Ten workflow as a bridge between standard ethereum ecosystem
tools.
![Diagram showing wallet extension as an RPC bridge for common Ethereum tooling](../../assets/images/RPC-Interfaces.png)
@@ -35,11 +35,11 @@ tools.
## Usage
-1. The wallet extension can be downloaded from the [Obscuro release page](https://github.com/obscuronet/go-obscuro/releases)
+1. The wallet extension can be downloaded from the [Ten release page](https://github.com/ten-protocol/go-ten/releases)
where the binary is built for the Linux, MacOS and Windows platforms. Download the binary for the latest release and
rename to `wallet_extension`. Note that on MacOS the binary has not been signed and notarised yet - see
[apple support](https://support.apple.com/en-gb/HT202491) for steps to over-write this. The binary can be compiled by
- cloning the [Obscuro repository](https://github.com/obscuronet/go-obscuro) and running the following command from the
+ cloning the [Ten repository](https://github.com/ten-protocol/go-ten) and running the following command from the
root of the repository:
```
@@ -54,9 +54,9 @@ tools.
* `port` (default: `3000`): The local port on which to serve the wallet extension.
* `portWS` (default: `3001`): The local port on which to handle websocket requests.
- * `nodeHost` (default: `erpc.sepolia-testnet.obscu.ro`): The Obscuro node for the RPC connection.
- * `nodePortHTTP` (default: `80`): The Obscuro node's HTTP RPC port.
- * `nodePortWS` (default: `81`): The Obscuro node's websockets RPC port.
+ * `nodeHost` (default: `erpc.sepolia-testnet.obscu.ro`): The Ten node for the RPC connection.
+ * `nodePortHTTP` (default: `80`): The Ten node's HTTP RPC port.
+ * `nodePortWS` (default: `81`): The Ten node's websockets RPC port.
* `logPath` (default: `wallet_extension_logs.txt`): The path for the wallet extension's logs.
* `databasePath` (default: `~/.obscuro/getway_database`): The path to use for the wallet extension's
database.
@@ -64,7 +64,7 @@ tools.
The wallet extension is now listening on the specified host and port. For the remainder of this document, we'll
assume that the default ports of `3000` and `3001` were selected.
-3. Sign in to MetaMask and add the Obscuro Testnet network following the instructions [here](https://docs.obscu.ro/wallet-extension/configure-metamask).
+3. Sign in to MetaMask and add the Ten Testnet network following the instructions [here](https://docs.obscu.ro/wallet-extension/configure-metamask).
4. At this stage, no viewing key has been set up. The enclave will refuse to respond to sensitive RPC requests such
as `eth_getBalance`, `eth_call` and `eth_getTransactionReceipt`. As a result, your balance in MetaMask will not be
@@ -79,4 +79,4 @@ tools.
# Auditing the source
-The source code for the wallet extension can be found [here](https://github.com/obscuronet/go-obscuro/tree/main/tools/walletextension).
+The source code for the wallet extension can be found [here](https://github.com/ten-protocol/go-ten/tree/main/tools/walletextension).
diff --git a/docs/_docs/what-is-obscuro/encrypted-ethereum.md b/docs/_docs/what-is-obscuro/encrypted-ethereum.md
index 064842d1f7..34397ad0c5 100644
--- a/docs/_docs/what-is-obscuro/encrypted-ethereum.md
+++ b/docs/_docs/what-is-obscuro/encrypted-ethereum.md
@@ -3,6 +3,6 @@
# Encrypted Ethereum
_The full Litepaper is available to view [here](https://obscu.ro/litepaper)._
-Obscuro brings to Ethereum what HTTPS brought to Web 2 leading to an explosion in applications and usage. Obscuro achieves this goal by building an encrypted Ethereum Layer 2, leveraging the consensus and security of Ethereum.
+Ten brings to Ethereum what HTTPS brought to Web 2 leading to an explosion in applications and usage. Ten achieves this goal by building an encrypted Ethereum Layer 2, leveraging the consensus and security of Ethereum.
-As a Layer 2 solution, Obscuro enables faster and more cost-effective transactions while inheriting the security of Ethereum. Obscuro ensures that all inputs, contract state, and execution processes are encrypted, providing a Web2 experience with no changes to the user or developer experience. Obscuro revolutionizes Web3 applications, including gaming, DeFi 2.0, dark pool trading, sealed auctions, private agreements, identity, and more.
\ No newline at end of file
+As a Layer 2 solution, Ten enables faster and more cost-effective transactions while inheriting the security of Ethereum. Ten ensures that all inputs, contract state, and execution processes are encrypted, providing a Web2 experience with no changes to the user or developer experience. Ten revolutionizes Web3 applications, including gaming, DeFi 2.0, dark pool trading, sealed auctions, private agreements, identity, and more.
\ No newline at end of file
diff --git a/docs/_docs/what-is-obscuro/privacy-matters.md b/docs/_docs/what-is-obscuro/privacy-matters.md
index 671df7fef8..30dfcba61b 100644
--- a/docs/_docs/what-is-obscuro/privacy-matters.md
+++ b/docs/_docs/what-is-obscuro/privacy-matters.md
@@ -3,16 +3,16 @@
# Privacy
_The full Litepaper is available to view [here](https://obscu.ro/litepaper)._
-The privacy Obscuro provides can be split into transactional and computational privacy.
+The privacy Ten provides can be split into transactional and computational privacy.
## Transactional privacy
Transactional privacy is the ability to maintain privacy over transactions on the L2. For example, keeping user token balances, participants of a transaction and the amounts transferred private is the main use of transactional privacy.
This is the problem that ZKP-based privacy protocols such as Z-Cash solve.
-Obscuro provides transactional privacy and keeps token contract calls entirely confidential by encrypting transactions from the point of origination, the wallet.
+Ten provides transactional privacy and keeps token contract calls entirely confidential by encrypting transactions from the point of origination, the wallet.
## Computational privacy
-In addition to transactional privacy, Obscuro also provides a much deeper form of privacy known as computational privacy. This is complete and absolute privacy over the entire computation of smart contracts and the network.
+In addition to transactional privacy, Ten also provides a much deeper form of privacy known as computational privacy. This is complete and absolute privacy over the entire computation of smart contracts and the network.
With computational privacy, it's possible to keep inputs and outputs from contracts private and any logic executed within the smart contract. This opens up huge possibilities across DeFi, NFTs, Gaming, DAOs, the Metaverse and things yet to come.
\ No newline at end of file
diff --git a/docs/_docs/what-is-obscuro/quick-start.md b/docs/_docs/what-is-obscuro/quick-start.md
index ea420665d8..0016241ade 100644
--- a/docs/_docs/what-is-obscuro/quick-start.md
+++ b/docs/_docs/what-is-obscuro/quick-start.md
@@ -2,22 +2,22 @@
---
# Developer quick start
-The only difference between an Obscuro and an Ethereum (or Arbitrum) dApp is that on Obscuro you can hide the internal
+The only difference between an Ten and an Ethereum (or Arbitrum) dApp is that on Ten you can hide the internal
state of the contract.
-The most obvious example is that an ERC20 token deployed on Obscuro will not respond to balance requests unless you are
+The most obvious example is that an ERC20 token deployed on Ten will not respond to balance requests unless you are
the account owner.
-In Obscuro, the internal node database is encrypted, and the contract execution is also encrypted inside the TEE.
+In Ten, the internal node database is encrypted, and the contract execution is also encrypted inside the TEE.
The calls to [getStorageAt](https://docs.alchemy.com/reference/eth-getstorageat) are disabled, so all data access
requests will be performed through view functions which are under the control of the smart contract developer.
Nobody (which includes node operators and the sequencer) can access the internal state of a contract.
-**The only thing you have to do when porting a dApp to Obscuro is to add a check in your view functions comparing
+**The only thing you have to do when porting a dApp to Ten is to add a check in your view functions comparing
the `tx.origing` and `msg.sender` against the accounts allowed to access that data.**
-The snippet below illustrates this for an [ERC20 token](https://github.com/obscuronet/sample-applications/blob/main/number-guessing-game/contracts/ERC20.sol#L25).
+The snippet below illustrates this for an [ERC20 token](https://github.com/ten-protocol/sample-applications/blob/main/number-guessing-game/contracts/ERC20.sol#L25).
```solidity
function balanceOf(address tokenOwner) public view override returns (uint256) {
@@ -26,4 +26,4 @@ function balanceOf(address tokenOwner) public view override returns (uint256) {
}
```
-_Note that this works because in Obscuro all calls to view functions are authenticated._
\ No newline at end of file
+_Note that this works because in Ten all calls to view functions are authenticated._
\ No newline at end of file
diff --git a/docs/_docs/what-is-obscuro/technology.md b/docs/_docs/what-is-obscuro/technology.md
index 18c17de95c..5bc631f9d7 100644
--- a/docs/_docs/what-is-obscuro/technology.md
+++ b/docs/_docs/what-is-obscuro/technology.md
@@ -2,6 +2,6 @@
---
# Technology
-Obscuro leverages a pragmatic technology for encrypting the ledger, Trusted Execution Environments (TEEs). TEEs provide robust confidentiality guarantees with certainty over the code running. They allow Obscuro to offer smart contracts, decentralisation, scalability and encryption in a way not seen before.
+Ten leverages a pragmatic technology for encrypting the ledger, Trusted Execution Environments (TEEs). TEEs provide robust confidentiality guarantees with certainty over the code running. They allow Ten to offer smart contracts, decentralisation, scalability and encryption in a way not seen before.
-Obscuro brings encryption to the Ethereum Mainnet, leveraging the liveness and availability of the Mainnet for ledger integrity. Uniquely, Obscuro’s Proof of Block Inclusion (POBI) protocol ensures Obscuro's confidential roll-ups have consensus in a decentralized Obscuro network.
\ No newline at end of file
+Ten brings encryption to the Ethereum Mainnet, leveraging the liveness and availability of the Mainnet for ledger integrity. Uniquely, Ten’s Proof of Block Inclusion (POBI) protocol ensures Ten's confidential roll-ups have consensus in a decentralized Ten network.
\ No newline at end of file
diff --git a/docs/_docs/what-is-obscuro/user-experience.md b/docs/_docs/what-is-obscuro/user-experience.md
index e0b1dc33ce..7480267188 100644
--- a/docs/_docs/what-is-obscuro/user-experience.md
+++ b/docs/_docs/what-is-obscuro/user-experience.md
@@ -2,6 +2,6 @@
---
# User Experience
-The design of Obscuro ensures that existing Ethereum dApps can move over to Obscuro for virtually no cost. Any developer familiar with Ethereum can build encrypted dApps on Obscuro that benefit from the adoption, legitimacy, security, developer tooling and liquidity of the entire Ethereum ecosystem.
+The design of Ten ensures that existing Ethereum dApps can move over to Ten for virtually no cost. Any developer familiar with Ethereum can build encrypted dApps on Ten that benefit from the adoption, legitimacy, security, developer tooling and liquidity of the entire Ethereum ecosystem.
-End-users can continue to use MetaMask or their favourite Ethereum wallet. Interacting with an Obscuro application is the same as interacting with any Ethereum application. With a seamless user and developer experience, Obscuro changes the paradigm around encryption for web3.
+End-users can continue to use MetaMask or their favourite Ethereum wallet. Interacting with an Ten application is the same as interacting with any Ethereum application. With a seamless user and developer experience, Ten changes the paradigm around encryption for web3.
diff --git a/docs/index.md b/docs/index.md
index f78efcb44a..d39421ad95 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -2,11 +2,11 @@