From 0ec2d0530e501e82798de7359e3a7c350bda8212 Mon Sep 17 00:00:00 2001 From: Tudor Malene Date: Thu, 16 Nov 2023 14:29:49 +0000 Subject: [PATCH] rebranding .md files (#1648) * rebranding .md files * rebranding .md files * rebranding .md files * revert changelog --- README.md | 88 +++++++++---------- contracts/README.md | 10 +-- contracts/src/README.md | 2 +- design/README.md | 8 +- design/architecture/overall_design.md | 20 ++--- design/architecture/tech_decisions.md | 6 +- design/bridge/bridge_design.md | 68 +++++++------- .../Soft_finality_guarantee.md | 14 +-- design/finality_protocol/fast_finality.md | 6 +- .../sequencer_bootstrapping_strategy.md | 14 +-- design/scratchpad/Design_escape_hatch.md | 6 +- design/security/Escape_hatch.md | 4 +- design/security/Source_of_truth.md | 32 +++---- design/security/Upgrade_Design.md | 34 +++---- design/security/cryptography.md | 26 +++--- design/security/high_availability.md | 8 +- design/security/randomness_design.md | 6 +- design/ux/Events_design.md | 24 ++--- design/ux/Obscuro_Gateway.md | 50 +++++------ design/ux/block_explorer.md | 12 +-- design/ux/user_data_incentives.md | 6 +- design/ux/wallet_extension.md | 20 ++--- developer_onboarding_guide.md | 8 +- dockerfiles/README.md | 12 +-- docs/README.md | 8 +- docs/_docs/api/apis.md | 6 +- docs/_docs/api/debug-apis.md | 4 +- docs/_docs/api/sensitive-apis.md | 2 +- docs/_docs/community/contributions.md | 8 +- docs/_docs/cross-chain/bridge.md | 14 +-- .../_docs/cross-chain/core-messaging-layer.md | 6 +- docs/_docs/testnet/Introduction.md | 12 +-- docs/_docs/testnet/changelog.md | 2 +- ...oying-a-smart-contract-programmatically.md | 10 +-- .../testnet/deploying-a-smart-contract.md | 30 +++---- docs/_docs/testnet/essentials.md | 12 +-- docs/_docs/testnet/example-dapps.md | 16 ++-- docs/_docs/testnet/faucet.md | 12 +-- docs/_docs/testnet/obscuroscan.md | 12 +-- docs/_docs/testnet/security.md | 4 +- docs/_docs/testnet/starting-a-node.md | 12 +-- docs/_docs/testnet/tutorial.md | 34 +++---- .../wallet-extension/configure-metamask.md | 4 +- .../wallet-extension/wallet-extension.md | 28 +++--- .../what-is-obscuro/encrypted-ethereum.md | 4 +- docs/_docs/what-is-obscuro/privacy-matters.md | 6 +- docs/_docs/what-is-obscuro/quick-start.md | 12 +-- docs/_docs/what-is-obscuro/technology.md | 4 +- docs/_docs/what-is-obscuro/user-experience.md | 4 +- docs/index.md | 10 +-- go/enclave/crypto/README.md | 2 +- go/enclave/evm/README.md | 2 +- go/enclave/l2chain/README.md | 2 +- go/enclave/rpc/README.md | 4 +- go/enclave/storage/README.md | 2 +- go/enclave/storage/enclavedb/README.md | 4 +- go/node/README.md | 2 +- go/obsclient/README.md | 8 +- go/rpc/README.md | 4 +- integration/README.md | 2 +- integration/manualtests/tx_test.go | 6 +- integration/obscuroscan/obscuroscan_test.go | 2 +- integration/simulation/params/params.go | 2 +- planning/Testnet release plan.md | 2 +- planning/testnet-kpis.md | 20 ++--- pull_request_template.md | 2 +- tools/faucet/README.md | 12 +-- tools/faucet/faucet/faucet.go | 4 +- tools/faucet/webserver/web_server.go | 2 +- tools/gateway-js/gateway-lib/README.md | 14 +-- tools/hardhatdeployer/README.md | 4 +- tools/obscuroscan/README.md | 2 +- tools/walletextension/README.md | 4 +- tools/walletextension/lib/README.md | 2 +- 74 files changed, 435 insertions(+), 435 deletions(-) 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/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..d70fd0ba81 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; 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 @@

-Welcome to Obscuro - the first Ethereum L2 with private smart contract state. +Welcome to Ten - the first Ethereum L2 with private smart contract state. -Obscuro hyper-scales and encrypts Ethereum. 100% EVM, 100% Solidity. +Ten hyper-scales and encrypts Ethereum. 100% EVM, 100% Solidity. -On this docsite you will find useful guidance on Obscuro, how to participate in the Testnet and, if you want to go deeper, read the whitepaper using the menu above. +On this docsite you will find useful guidance on Ten, how to participate in the Testnet and, if you want to go deeper, read the whitepaper using the menu above. The Litepaper is available to view [here](https://obscu.ro/litepaper). @@ -15,7 +15,7 @@ A PDF version of the whitepaper is available [here](https://whitepaper.obscu.ro/ ## Useful Resources -1. [Github](https://github.com/obscuronet/go-obscuro) -2. [Twitter](https://twitter.com/obscuronet/) +1. [Github](https://github.com/ten-protocol/go-ten) +2. [Twitter](https://twitter.com/tenprotocol/) 3. [Discord](https://discord.gg/7pkKv2Tyfn) 4. [Blog](https://medium.com/obscuro-labs) diff --git a/go/enclave/crypto/README.md b/go/enclave/crypto/README.md index 42b69b8bdd..8adee3086b 100644 --- a/go/enclave/crypto/README.md +++ b/go/enclave/crypto/README.md @@ -1 +1 @@ -This package contains logic which implements the cryptographic requirements of Obscuro. \ No newline at end of file +This package contains logic which implements the cryptographic requirements of Ten. \ No newline at end of file diff --git a/go/enclave/evm/README.md b/go/enclave/evm/README.md index 70a4ffb5d3..1c9fabe500 100644 --- a/go/enclave/evm/README.md +++ b/go/enclave/evm/README.md @@ -1,4 +1,4 @@ -Obscuro executes EVM compatible transactions on top of a database that implements the Go-Ethereum interfaces. +Ten executes EVM compatible transactions on top of a database that implements the Go-Ethereum interfaces. The entry point is the evm_facade. diff --git a/go/enclave/l2chain/README.md b/go/enclave/l2chain/README.md index 8ed73fb75f..2ea92b5492 100644 --- a/go/enclave/l2chain/README.md +++ b/go/enclave/l2chain/README.md @@ -1,4 +1,4 @@ -This is where the bulk of the Obscuro specific logic is. +This is where the bulk of the Ten specific logic is. The entry point is the `L2Chain`. Ethereum Blocks and Rollups produced by peers are fed into this datastructure, and it decides which is the canonical chain, diff --git a/go/enclave/rpc/README.md b/go/enclave/rpc/README.md index 9f70723331..1b970bc7f6 100644 --- a/go/enclave/rpc/README.md +++ b/go/enclave/rpc/README.md @@ -1,2 +1,2 @@ -All communication to and from Obscuro is encrypted. -This package handles the encryption logic between end users communicating via RPC with the Obscuro enclave. \ No newline at end of file +All communication to and from Ten is encrypted. +This package handles the encryption logic between end users communicating via RPC with the Ten enclave. \ No newline at end of file diff --git a/go/enclave/storage/README.md b/go/enclave/storage/README.md index 69adf2f315..389586d5d1 100644 --- a/go/enclave/storage/README.md +++ b/go/enclave/storage/README.md @@ -1,4 +1,4 @@ -This package implements the storage requirements of Obscuro. +This package implements the storage requirements of Ten. - The services it exposes are available in "interfaces.go". - The storage is created using: ``NewStorageFromConfig`` \ No newline at end of file diff --git a/go/enclave/storage/enclavedb/README.md b/go/enclave/storage/enclavedb/README.md index 5254e2ae42..f243e7a8e7 100644 --- a/go/enclave/storage/enclavedb/README.md +++ b/go/enclave/storage/enclavedb/README.md @@ -5,8 +5,8 @@ Currently, it is at the first version which is a little rough. ### Historical reasoning for the current design: 1. Geth is implemented on top of levelDB, and so makes heavy use of the k/v mechanism. -2. Obscuro uses EdglessDb in production, and sqlite in testing. -3. Obscuro started out by implementing the k/v primitives on top of sql. +2. Ten uses EdglessDb in production, and sqlite in testing. +3. Ten started out by implementing the k/v primitives on top of sql. 4. Then we decided to use the SQL features to simplify some business logic, which required exposing the sql primitives. 5. Eventually, we ended up using SQL for everything, except the evm functionality. diff --git a/go/node/README.md b/go/node/README.md index cdeda5439d..1acf839a88 100644 --- a/go/node/README.md +++ b/go/node/README.md @@ -1,3 +1,3 @@ # Node package -This package is responsible for orchestrating the start of various components that make up the obscuro node. +This package is responsible for orchestrating the start of various components that make up the ten node. diff --git a/go/obsclient/README.md b/go/obsclient/README.md index 4ac72cf241..7ab9b3a2fb 100644 --- a/go/obsclient/README.md +++ b/go/obsclient/README.md @@ -1,12 +1,12 @@ This package is analogous to the ethclient package in go-ethereum. -It provides a higher level, standard way to interact with an Obscuro network programmatically. +It provides a higher level, standard way to interact with an Ten network programmatically. -It aims to provide all the same methods that the geth ethclient provides for compatibility/familiarity, as well as obscuro-specific methods. +It aims to provide all the same methods that the geth ethclient provides for compatibility/familiarity, as well as ten-specific methods. There are two clients, `ObsClient` and `AuthObsClient` -`ObsClient` just requires a Client and provides access to general Obscuro functionality that doesn't require viewing keys. +`ObsClient` just requires a Client and provides access to general Ten functionality that doesn't require viewing keys. `AuthObsClient` requires a EncRPCClient, which is an RPC client with an account and a signed Viewing Key for authentication. -It provides full Obscuro functionality, authenticating with the node and encrypting/decrypting sensitive requests. \ No newline at end of file +It provides full Ten functionality, authenticating with the node and encrypting/decrypting sensitive requests. \ No newline at end of file diff --git a/go/rpc/README.md b/go/rpc/README.md index d1303e33ca..98e975e405 100644 --- a/go/rpc/README.md +++ b/go/rpc/README.md @@ -1,8 +1,8 @@ -This package contains library code to allow client applications to connect to Obscuro nodes via RPC. +This package contains library code to allow client applications to connect to Ten nodes via RPC. ### Viewing keys -Viewing keys are generated inside the wallet extension (or other users of the obscuro rpc client), and then signed by the wallet (e.g. MetaMask) +Viewing keys are generated inside the wallet extension (or other users of the ten rpc client), and then signed by the wallet (e.g. MetaMask) to which the keys relate. The keys are then are sent to the enclave via RPC and processed by: - checking the validity of the signature over the viewing key diff --git a/integration/README.md b/integration/README.md index e567c3428a..3d3fc67b46 100644 --- a/integration/README.md +++ b/integration/README.md @@ -1,4 +1,4 @@ -These packages contain code related to the simulation and testing an end-to-end Obscuro network. +These packages contain code related to the simulation and testing an end-to-end Ten network. To include the Docker tests when running the tests, build the Docker images using the instructions in the `dockerfiles/` folder, then run the tests with the `docker` tag (e.g. `go test -v -tags docker ./...`). diff --git a/integration/manualtests/tx_test.go b/integration/manualtests/tx_test.go index 3d27831ab9..614770d074 100644 --- a/integration/manualtests/tx_test.go +++ b/integration/manualtests/tx_test.go @@ -154,7 +154,7 @@ func TestL2IssueContractInteractWaitReceipt(t *testing.T) { require.NoError(t, err) if balance.Cmp(big.NewInt(0)) <= 0 { - t.Errorf("not enough balance: has %s has %s obx", l2Wallet.Address().Hex(), balance.String()) + t.Errorf("not enough balance: has %s has %s ten", l2Wallet.Address().Hex(), balance.String()) } storeContractBytecode := "0x608060405234801561001057600080fd5b506101f3806100206000396000f3fe608060405234801561001057600080fd5b50600436106100365760003560e01c80632e64cec11461003b5780636057361d14610059575b600080fd5b610043610075565b60405161005091906100da565b60405180910390f35b610073600480360381019061006e9190610126565b61007e565b005b60008054905090565b806000819055507febfcf7c0a1b09f6499e519a8d8bb85ce33cd539ec6cbd964e116cd74943ead1a33826040516100b6929190610194565b60405180910390a150565b6000819050919050565b6100d4816100c1565b82525050565b60006020820190506100ef60008301846100cb565b92915050565b600080fd5b610103816100c1565b811461010e57600080fd5b50565b600081359050610120816100fa565b92915050565b60006020828403121561013c5761013b6100f5565b5b600061014a84828501610111565b91505092915050565b600073ffffffffffffffffffffffffffffffffffffffff82169050919050565b600061017e82610153565b9050919050565b61018e81610173565b82525050565b60006040820190506101a96000830185610185565b6101b660208301846100cb565b939250505056fea264697066735822122071ae4262a5da0c5c7b417d9c6cd13b57b8fcfe79c9c526b96f482ee67ff3136c64736f6c63430008120033" @@ -327,7 +327,7 @@ func TestL2IssueTxWaitReceipt(t *testing.T) { require.NoError(t, err) if balance.Cmp(big.NewInt(0)) <= 0 { - t.Fatalf("not enough balance: has %s has %s obx", l2Wallet.Address().Hex(), balance.String()) + t.Fatalf("not enough balance: has %s has %s ten", l2Wallet.Address().Hex(), balance.String()) } fmt.Println("balance: ", balance.String()) @@ -394,7 +394,7 @@ func TestL2IssueContractSubscribeChange(t *testing.T) { require.NoError(t, err) if balance.Cmp(big.NewInt(0)) <= 0 { - t.Errorf("not enough balance: has %s has %s obx", l2Wallet.Address().Hex(), balance.String()) + t.Errorf("not enough balance: has %s has %s ten", l2Wallet.Address().Hex(), balance.String()) } storeContractBytecode := "608060405234801561001057600080fd5b506101d7806100206000396000f3fe608060405234801561001057600080fd5b506004361061002b5760003560e01c80630f2723ea14610030575b600080fd5b61004a60048036038101906100459190610137565b61004c565b005b8173ffffffffffffffffffffffffffffffffffffffff167fe86bd59ccd77aa1a9fbc46604e341e1dcc72f2a6e6637d5422736d645a71625e826040516100929190610186565b60405180910390a25050565b600080fd5b600073ffffffffffffffffffffffffffffffffffffffff82169050919050565b60006100ce826100a3565b9050919050565b6100de816100c3565b81146100e957600080fd5b50565b6000813590506100fb816100d5565b92915050565b6000819050919050565b61011481610101565b811461011f57600080fd5b50565b6000813590506101318161010b565b92915050565b6000806040838503121561014e5761014d61009e565b5b600061015c858286016100ec565b925050602061016d85828601610122565b9150509250929050565b61018081610101565b82525050565b600060208201905061019b6000830184610177565b9291505056fea2646970667358221220d45d57b217a07cfd4ceecc8f5d2a9194a098e5fe1de98bc56c24cc400e21c96064736f6c63430008120033" diff --git a/integration/obscuroscan/obscuroscan_test.go b/integration/obscuroscan/obscuroscan_test.go index 2630091079..a1da72df1f 100644 --- a/integration/obscuroscan/obscuroscan_test.go +++ b/integration/obscuroscan/obscuroscan_test.go @@ -235,7 +235,7 @@ func issueTransactions(t *testing.T, hostWSAddr string, issuerWallet wallet.Wall assert.Nil(t, err) if balance.Cmp(big.NewInt(0)) <= 0 { - t.Errorf("not enough balance: has %s has %s obx", issuerWallet.Address().Hex(), balance.String()) + t.Errorf("not enough balance: has %s has %s ten", issuerWallet.Address().Hex(), balance.String()) } nonce, err := authClient.NonceAt(ctx, nil) diff --git a/integration/simulation/params/params.go b/integration/simulation/params/params.go index e550820b6a..40612ca3b3 100644 --- a/integration/simulation/params/params.go +++ b/integration/simulation/params/params.go @@ -46,7 +46,7 @@ type L1SetupData struct { ObscuroStartBlock common.Hash // MgmtContractAddr defines the management contract address MgmtContractAddress common.Address - // ObxErc20Address - the address of the "OBX" ERC20 + // ObxErc20Address - the address of the "TEN" ERC20 ObxErc20Address common.Address // EthErc20Address - the address of the "ETH" ERC20 EthErc20Address common.Address diff --git a/planning/Testnet release plan.md b/planning/Testnet release plan.md index abf6fe56e2..40fedda06e 100644 --- a/planning/Testnet release plan.md +++ b/planning/Testnet release plan.md @@ -24,7 +24,7 @@ Note that there is no protocol work listed here. These are the tasks that are or d) Try outside of Azure? 2. Design and implement reveleation period 3. Finalise cryptography - a) key derivation (both the obscuro network key, and the symmetric rollup encryption keys) + a) key derivation (both the ten network key, and the symmetric rollup encryption keys) b) Calculate hashes on startup c) Check that the rollup producer is attested d) Add entropy to txs diff --git a/planning/testnet-kpis.md b/planning/testnet-kpis.md index 807a5385f4..d785c01385 100644 --- a/planning/testnet-kpis.md +++ b/planning/testnet-kpis.md @@ -1,8 +1,8 @@ # Measuring Testnet Success -The launch of a testnet in Web3 is a significant milestone for all projects. It demonstrates the capability of the solution, whether the project is likely to meet the promises shared with investors and with the community and it signifies a confident step towards mainnet. The final iterations of a testnet should very closely emulate mainnet and give assurances to users, developers and investors that the final product will be of a high quality with a high chance of success. As a result, the impression left by testnet is crucial to the expected success of a project and how it is perceived. The primary contributors of success for Obscuro testnet are whether it is attractive, it is being used and whether or not users have a positive experience with it. Making the degree of success quantifiable means defining mesaurable success criteria and collecting data to know whether those criteria are being met. +The launch of a testnet in Web3 is a significant milestone for all projects. It demonstrates the capability of the solution, whether the project is likely to meet the promises shared with investors and with the community and it signifies a confident step towards mainnet. The final iterations of a testnet should very closely emulate mainnet and give assurances to users, developers and investors that the final product will be of a high quality with a high chance of success. As a result, the impression left by testnet is crucial to the expected success of a project and how it is perceived. The primary contributors of success for Ten testnet are whether it is attractive, it is being used and whether or not users have a positive experience with it. Making the degree of success quantifiable means defining mesaurable success criteria and collecting data to know whether those criteria are being met. ## Testnet Success Criteria -Determining success for testnet will be a data-driven exercise, this being the best way to make measurable and repeatable observations. These observations can subsquently feed into decision-making with outcomes again being measured and compared. Included in the measurements will be criteria which, on the face of it, do not provide value however they have gained traction in the Web3 communicty as success indicators by which projects are judged. We need commentators to be able to compare Obscuro to other projects using like-for-like data points which the Web3 community are comfortable with even if they offer little value, or can even be misleading. For example, total number of transactions in a given period of time is a data point commonly used to compare projects yet it can be easily gamed. +Determining success for testnet will be a data-driven exercise, this being the best way to make measurable and repeatable observations. These observations can subsquently feed into decision-making with outcomes again being measured and compared. Included in the measurements will be criteria which, on the face of it, do not provide value however they have gained traction in the Web3 communicty as success indicators by which projects are judged. We need commentators to be able to compare Ten to other projects using like-for-like data points which the Web3 community are comfortable with even if they offer little value, or can even be misleading. For example, total number of transactions in a given period of time is a data point commonly used to compare projects yet it can be easily gamed. The testnet success critera have been expressed below in the form of Key Performance Indicators with the rationale for their inclusion, the data source, the actual metric and the target value. ## Testnet KPIs @@ -11,8 +11,8 @@ Key performance indicators (KPIs) will be used to determine the amount of Testne ### Selected KPIs for Users | KPI NAME | RATIONALE | SOURCE | METRIC | TARGET | |--|--|--|--|--| -| Testnet uptime | Captures how robust and ready for mainnet Obscuro is | DataDog avg:system.uptime{*} | Average Testnet uptime over the last 4 weeks|99.9%| -| Number of wallets connected to Obscuro Gateway| Good proxy for the number of active users. Straightforward to capture.| Datadog? |Number of daily connections|500| +| Testnet uptime | Captures how robust and ready for mainnet Ten is | DataDog avg:system.uptime{*} | Average Testnet uptime over the last 4 weeks|99.9%| +| Number of wallets connected to Ten Gateway| Good proxy for the number of active users. Straightforward to capture.| Datadog? |Number of daily connections|500| | Number of transactions| Typical guage of the amount of activity on testnet (even though it can be gamed).| Datadog? |Number of daily transactions|2000| | Number of RPC requests| Alternative guage of the amount of activity on testnet. Can also show where RPC performance degrades.| Datadog? |Number of daily RPC requests|2000| @@ -21,7 +21,7 @@ Key performance indicators (KPIs) will be used to determine the amount of Testne |--|--|--|--|--| | Testnet documentation page views (https://docs.obscu.ro/testnet/) | Gauges interest from developers in building on testnet. A good early indicator. Straightforward to capture | Google Analytics | Number of unique page views in the last 4 weeks |50| |DApps in development| This is difficult to measure as it’s not something we can look to the network to accurately measure. We can use our business development CRM data as an indicator. | Airtable "Partnerships" tab| Number of partners with status changed to "Soft Commitment" in the last 4 weeks|40| -| New dApps deployed on Testnet| Indicates how much new activity and commitment of effort from dApp builders| ObscuroScan?| Number of new dApp addresses deployed in the last 4 weeks|20| +| New dApps deployed on Testnet| Indicates how much new activity and commitment of effort from dApp builders| TenScan?| Number of new dApp addresses deployed in the last 4 weeks|20| ## Discounted KPIs These KPIs were considered and discounted for now. @@ -29,17 +29,17 @@ These KPIs were considered and discounted for now. - Wallet extension downloads - Good proxy for the number of active users. - Straightforward to capture. - - Discounted because Obscuro Gateway is the recommended wallet connection method. + - Discounted because Ten Gateway is the recommended wallet connection method. - Ported Solidity dApps– original vs fork - - One of Obscuro’s key promises is that existing Solidity dApps will just work on Obscuro. This KPI helps track whether Obscuro is fulfilling this promise. The reason for differentiating between original fork e.g. Uniswap vs PancakeSwap is it further provides insight into whether original teams believe in Obscuro. + - One of Ten’s key promises is that existing Solidity dApps will just work on Ten. This KPI helps track whether Ten is fulfilling this promise. The reason for differentiating between original fork e.g. Uniswap vs PancakeSwap is it further provides insight into whether original teams believe in Ten. - Discounted because very difficult to determine of the dApps on Testnet which have been ported. - Number of nodes - - Nodes secure the network and track general interest in Obscuro. This KPI also provides an input into the staking function and has an impact on tokenomics. - - Discounted for now because Obscuro Labs will run the nodes. When validator nodes can be run by others, this KPI will be introduced. + - Nodes secure the network and track general interest in Ten. This KPI also provides an input into the staking function and has an impact on tokenomics. + - Discounted for now because Ten Labs will run the nodes. When validator nodes can be run by others, this KPI will be introduced. - Faucet requests - Tracks the number of tokens being requested and whether users are coming back for more. Straightforward to capture. - Discounted because it can be gamed too easily leading to misleading results. - Number of organisations building on Testnet - - Funded organisations building on Obscuro vs individuals. Good indicator of the long-term health of dApps being built on Obscuro and expands on number of new dApps. + - Funded organisations building on Ten vs individuals. Good indicator of the long-term health of dApps being built on Ten and expands on number of new dApps. - Discounted because large effort required to determine who is building on Testnet. diff --git a/pull_request_template.md b/pull_request_template.md index 08b7347b07..8b651e3edd 100644 --- a/pull_request_template.md +++ b/pull_request_template.md @@ -9,7 +9,7 @@ Please provide a high level list of the changes made ### PR checks pre-merging Please indicate below by ticking the checkbox that you have read and performed the required -[PR checks](https://github.com/obscuronet/obscuro-internal/blob/main/dev-ops-docs/dev-pr-checks.md) +[PR checks](https://github.com/ten-protocol/ten-internal/blob/main/dev-ops-docs/dev-pr-checks.md) - [ ] PR checks reviewed and performed diff --git a/tools/faucet/README.md b/tools/faucet/README.md index 1bc7e8a2bb..e2bf4994d6 100644 --- a/tools/faucet/README.md +++ b/tools/faucet/README.md @@ -1,7 +1,7 @@ -# Obscuro Faucet +# Ten Faucet -This tools contains a Faucet to allow allocation of ETH tokens within an Obscuro network. For more information -on Obscuro see the [Obscuro repo](https://github.com/obscuronet/go-obscuro) and [documentation](https://docs.obscu.ro/). +This tools contains a Faucet to allow allocation of ETH tokens within an Ten network. For more information +on Ten see the [Ten repo](https://github.com/ten-protocol/go-ten) and [documentation](https://docs.obscu.ro/). ## Repository Structure The top level structure of the tool is as below; @@ -24,9 +24,9 @@ To run a local container and run the Faucet use the below; $ ./container_run.sh ``` -By default, when running locally the Faucet will connect to a local testnet started as described in the go-obscuro -project repo [readme](https://github.com/obscuronet/go-obscuro#building-and-running-a-local-testnet). It will connect -to the Obscuro node running within the local testnet on host `validator-host` and port `13010`. The Faucet opens +By default, when running locally the Faucet will connect to a local testnet started as described in the go-ten +project repo [readme](https://github.com/ten-protocol/go-ten#building-and-running-a-local-testnet). It will connect +to the Ten node running within the local testnet on host `validator-host` and port `13010`. The Faucet opens on port `80` within the container, but maps port `8080` on the host machine to this. diff --git a/tools/faucet/faucet/faucet.go b/tools/faucet/faucet/faucet.go index a0da725431..7b4d46887e 100644 --- a/tools/faucet/faucet/faucet.go +++ b/tools/faucet/faucet/faucet.go @@ -21,8 +21,8 @@ import ( const ( _timeout = 60 * time.Second NativeToken = "eth" - // DeprecatedNativeToken is left in temporarily for tooling that is getting native funds using `/obx` URL - DeprecatedNativeToken = "obx" // todo (@matt) remove this once we have fixed the /obx usages + // DeprecatedNativeToken is left in temporarily for tooling that is getting native funds using `/ten` URL + DeprecatedNativeToken = "ten" // todo (@matt) remove this once we have fixed the /ten usages WrappedOBX = "wobx" WrappedEth = "weth" WrappedUSDC = "usdc" diff --git a/tools/faucet/webserver/web_server.go b/tools/faucet/webserver/web_server.go index 77b944b763..c0f9b133df 100644 --- a/tools/faucet/webserver/web_server.go +++ b/tools/faucet/webserver/web_server.go @@ -118,7 +118,7 @@ func fundingHandler(faucetServer *faucet.Faucet, defaultAmount *big.Int) gin.Han switch tokenReq { case faucet.NativeToken: token = faucet.NativeToken - // we leave this option in temporarily for tools that are still using `/obx` endpoint for native funds + // we leave this option in temporarily for tools that are still using `/ten` endpoint for native funds case faucet.DeprecatedNativeToken: token = faucet.NativeToken case faucet.WrappedOBX: diff --git a/tools/gateway-js/gateway-lib/README.md b/tools/gateway-js/gateway-lib/README.md index d22b51c6a4..10bdce0ff5 100644 --- a/tools/gateway-js/gateway-lib/README.md +++ b/tools/gateway-js/gateway-lib/README.md @@ -1,6 +1,6 @@ -# Obscuro Gateway JS +# Ten Gateway JS -A JavaScript library for the gateway, providing streamlined access and functionalities for interacting with the Obscuro network. +A JavaScript library for the gateway, providing streamlined access and functionalities for interacting with the Ten network. ## Table of Contents @@ -13,23 +13,23 @@ A JavaScript library for the gateway, providing streamlined access and functiona ## Features -- Seamless connection to Obscuro Network. +- Seamless connection to Ten Network. - Easy-to-use methods for joining and authenticating. - External consumption support through CDN or NPM. ## Installation -To install `obscuro-gateway-js`, use npm: +To install `ten-gateway-js`, use npm: \`\`\`bash -npm install obscuro-gateway-js +npm install ten-gateway-js \`\`\` ## Usage \`\`\`javascript -const Gateway = require('obscuro-gateway-js'); +const Gateway = require('ten-gateway-js'); const gateway = new Gateway(httpURL, wsURL, provider); await gateway.join(); @@ -51,7 +51,7 @@ For production: npm run build \`\`\` -The production build will be available for external consumption on GitHub Pages at `https://go-obscuro.github.io/obscuronet/gateway.bundle.js`. +The production build will be available for external consumption on GitHub Pages at `https://go-ten.github.io/tennet/gateway.bundle.js`. ## Contribute diff --git a/tools/hardhatdeployer/README.md b/tools/hardhatdeployer/README.md index 261ba7b081..1ab5a21cb6 100644 --- a/tools/hardhatdeployer/README.md +++ b/tools/hardhatdeployer/README.md @@ -1,6 +1,6 @@ # Contract deployer -Deploys contracts to both the obscuro network (L2) and eth network (L1) +Deploys contracts to both the ten network (L2) and eth network (L1) ## Usage @@ -8,7 +8,7 @@ All commands are executed by running `contractdeployer/main/main()`. Contract is a string value to select the contract bytecode to deploy, currently ERC20, and MGMT are supported: - `ERC20`: a standard ERC20 contract -- `MGMT`: the Obscuro L1 management contract +- `MGMT`: the Ten L1 management contract * Example arguments to deploy an L2 contract: diff --git a/tools/obscuroscan/README.md b/tools/obscuroscan/README.md index 016713c853..45ca80af22 100644 --- a/tools/obscuroscan/README.md +++ b/tools/obscuroscan/README.md @@ -1,4 +1,4 @@ -# Obscuroscan +# TenScan See the documentation [here](https://docs.obscu.ro/testnet/obscuroscan.html). diff --git a/tools/walletextension/README.md b/tools/walletextension/README.md index 7775f11bd2..0074b295bf 100644 --- a/tools/walletextension/README.md +++ b/tools/walletextension/README.md @@ -1,4 +1,4 @@ -# 👛 The Obscuro wallet extension +# 👛 The Ten wallet extension See the documentation [here](https://docs.obscu.ro/wallet-extension/wallet-extension/). @@ -31,7 +31,7 @@ To run the container you can use `./docker_run.sh`. You can add parameters to th ### HTTP Endpoints -For interacting with Obscuro Gateway, there are the following HTTP endpoints available: +For interacting with Ten Gateway, there are the following HTTP endpoints available: - `GET /v1/join` diff --git a/tools/walletextension/lib/README.md b/tools/walletextension/lib/README.md index 313078399a..4d0fd52ac1 100644 --- a/tools/walletextension/lib/README.md +++ b/tools/walletextension/lib/README.md @@ -1 +1 @@ -A golang based library to use the obscuro gateway programmatically. \ No newline at end of file +A golang based library to use the ten gateway programmatically. \ No newline at end of file