The Consumer Contract Wallet – Version 3.4.1 – 消费者合同钱包-版本3.4.1区块链毕设代写

区块链毕设代写本文提供国外最新区块链项目源码下载,包括solidity,eth,fabric等blockchain区块链,The Consumer Contract Wallet – Version 3.4.1 – 消费者合同钱包-版本3.4.1区块链毕设代写 是一篇很好的国外资料

The Consumer Contract Wallet – Version 3.4.1

This repository contains the Smart Contracts needed to power the Monolith App, written in Solidity, for execution in the EVM.

We are committed to building a non-custodial banking alternative on Ethereum and these contracts define our relationship with our users.

The Monolith Card is the world’s first non-custodial position to VISA debit card. The Consumer Contract Wallet allows people to hold their own assets, whilst being able to seamlessly move funds to a VISA debit card. 1% of all loads to the Monolith Cards are sent, by the user themselves, to the TKN Holder contract. This is used to back the Community Chest (aka the Asset Contract). The purpose of this on-chain infrastructure is provide the most seamless user experience when it comes to using crypto in the real-world, whilst maintaining a decentralised position.

High Level Architecture Security Features Solidity Code Running Contract Tests Resources

Overview

The functionality encoded in the Smart Contracts found in this repository have been designed to help users protect their tokens, by holding them within their own contract wallet that implements the logic defined in our Consumer Contract Wallet. Users of the contract wallet need to configure their wallet’s to their own liking. The logic defined within the Consumer Contract Wallet has been created to limit a user’s exposure to loss of tokens in the event that a user has had their Private Key compromised.

We believe there are three major problems facing the adoption and use of decentralised finances:

  • The issue that users with compromised private keys could end up losing all of their assets.
  • The issue that people are generally not good at keeping digital secrets safe, the potential loss of private keys.
  • The UX of decentralised finances and how they interplay into real-world payments.

This, version 3.3.1, of the Consumer Contract Wallet utilises the library/proxy pattern for the deployment of this smart contract. This pattern is mainly employed by (upgradeable smart contracts) but can also be adopted to provide effeciencies on chain. All users get given a proxy contract that outsources the logic to a central library contract. The Consumer Contract Wallet uses the proxy contracts developed by OpenZeppelin in their suite of (upgradeable contracts). It should be noted that the Consumer Contract Wallet builds on top of the Proxy contract used by developers wanting to build upgradeable smart contracts, this version of the contract wallet itself isn’t upgradeable. Users will still need to migrate between versions of the contract wallet to get the benefit of new features.

The Consumer Contract Wallet protects users by limiting their exposure to theft in the event that their private key becoming compromised. This version also brings ‘batched meta-transactions’ to the list of features of the contract wallet. Batched meta-transactions are flexible to the point where gas can be removed from equation or can be approximately paid for in any ERC20 token. By batching up meta-transactions we will be able to build a more compelling user experience, by utilising the composability of Smart Contract calls on Ethereum.

Each user deploys their own proxy contract, i.e. their contract wallet, that uses the logic defined in (wallet.sol) that in turn interacts with the TokenWhitelist (tokenWhitelist.sol) to get token exchange rates to enforce a user-defined daily spend limit. The exchange rates in the TokenWhitelist contract are periodically updated using an exchange rate Oracle (oracle.sol) that builds upon the Provable Things Ethereum APIs and CryptoCompare’s APIs.

Service discovery in the Consumer Contract Wallet is performed via the use of the Ethereum Name Service (ENS). For example, ENS is used to resolve the location of the TokenWhitelist contract, as well as to resolve the location of the Controller (controller.sol) contract. The TokenWhitelist is a list of tokens and their exchange rates that defines the set of tokens that are protected within a user’s wallet. It also determines which tokens can be used to load fiat on to a user’s Monolith card. Card load transactions are peformed by sending assets to the (licence.sol) contract that in turn takes a 1% fee and adds it to the (holder.sol) contract. The tokens sent to the holder contract are “cash ‘n’ burnable” by the (TKN ERC-20 Contract) in conjunction with the TKN Holder Contract. This Controller contract is used for administrative purposes only, rest assured this has no access to user’s funds. The controllers are used to perform 2FA functionality as well as administrative tasks on the Oracle and on the TokenWhitelist.

High-level Architecture

The Consumer Contract Wallet - Version 3.4.1 - 消费者合同钱包-版本3.4.1

Assumptions

  • Every user will have their own Public and Private key pair, aka the Owner Address.
  • Users SHOULD NEVER have to share the Private Key of their Owner Address with anyone.
  • There are a number of different “pots of tokens” for a given user:
    • The user’s entire ETH and ERC20 token assets stored within the Consumer Contract Wallet.
    • An amount of ETH used to pay for the gas – Gas Tank. The Gas Tank is a representation of the ETH on the user’s Owner Address. It should be noted that this ETH is NOT protected by the security features in the Consumer Contract Wallet as it resides outside of the Smart Contract. Note: in the current version (v3) meta-transactions are also supported i.e. the users can send trasnactions without having to top-up their Gas Tank. The way it works is the following: they sign the transsaction with their private key, a controller broadcasts it, the signature is validated by their contract and the original transaction is executed consecutively. The Gas Tank has been kept mainly for convenience and is gonna be removed entirely in the upcoming version.

Requirements

  • This Owner Address will own all of the user’s Smart Contracts and will be referred to as the Owner, this is sometimes referred to as an Externally Owned Address (EOA)
  • The Controller – Is a key hierarchy of administrative addresses, owned and operated by Token Group Ltd. These are used to provide convenience to our users.
  • The Consumer Contract Wallet needs to allow its Owner to configure how they wish to secure their tokens in their wallet.
  • There needs to be a convenient way to “top-up” the amount of ETH that lives on our user’s Owner Address aka Gas Tank via the Smart Contracts
  • The wallet’s design is intended to be as decentralised as possible. This will be achieved by eliminating access to user assets by third-parties and minimising reliance of third-party infrastructure in running the Consumer Contract Wallet.
  • Must help user protect their funds by minimising the risk in the event of their Owner Address‘s private key being compromised.
  • Provide the best UX possible.

Security Features

In order to help users protect their tokens in the event that their Private Key gets compromised, we present the following security features:

  • A Whitelist of Addresses – akin to a whitelist of payees in a banking application, this whitelist should be configured with a list of trusted addresses for each Owner of the Consumer Contract Wallet.
  • Daily Spending Limit – denominated in ETH. This is used to define how much can a user transfer in a given day if transferring assets to addresses outside their Whitelist.
  • Daily Gas Tank Top-up Limit – (Gas Tank) top-up daily limit denominated in ETH. This is used to define the daily limit of ETH that can be sent from a user’s Consumer Contract Wallet to their Address; this ETH is what is used to pay the network for gas.
  • Daily Card Load Limit – (Card Load Limit) card loading daily limit denominated in USD (technically speaking in a stablecoin like USDC). This is used to define the daily limit of tokens or ETH that can be sent from a user’s Consumer Contract Wallet for loading of the user’s TokenCard. This is currently set to 10K USD.

Configuration

There are three ways to configure a Consumer Contract Wallet:

  • via Constructor: Upon deployment of a new Consumer Contract Wallet the above security features are configured: a) by passing the desired value for the Daily Spending Limit to the constructor b2) by setting default values for the Daily Gas Tank Top-up Limit and Daily Card Load Limit, when deploying the Consumer Contract Wallet smart contract the to the Ethereum network. This is how the values are set when deploying a new instance of the Consumer Contract Wallet.
  • via a 1-time write pattern: Aside from default values and values passed in via the Constructor the user may do a 1-time write to the aforementioned Security Features. These allow the Address to change the values that power the security features. It is advised that users of the Consumer Contract Wallet set their security settings so that they can not longer be tampered with in the event that a user’s private key is compromised. Users should set these values once, otherwise an attacker would be able to configure their Smart Contract.
  • via a 2FA pattern: Where a user can submitChange a new value for one of the Security Features, then one of the Controller addresses needs to either OK the value change or not. It should be noted that due to the nature of the user AddressWhitelist where a user may add or remove items from their whitelist via the 2FA pattern, only one pending change to the user’s address whitelist can be in flight at a given point in time.

Naming convention

This section details the naming convention adopted in this codebase:

  • Contracts – should be Nouns
  • Functions – should be Verbs
  • Ables – Smart Contracts that are meant to be inherited and not standalone, i.e. they are Mixins, Snippets, Decorators …
  • Private contract scoped variables – all start with an underscore _
  • Private / internal functions – all start with an underscore _
  • Constructor parameters – all start with an underscore _ and end in one too, e.g. _ens_ this is to avoid shadowing
  • Function parameters – all start with an underscore _
  • Local variables – to functions should start without an underscore
  • Public contract scoped variables – should start without an underscore
  • Public functions – should start without an underscore
  • Crud functions – when there exist multiple actions on the same variable we will use the suffix to illustrate the action, for example : dailySpendLimitSet, and dailySpendLimitUpdate

Solidity code in the /contracts/ folder

It should be noted that this codebase makes heavy use of inheritance.

wallet.sol is the library contract that defines the business logic of the Consumer Contract Wallet. This library is used to secure user funds. The Wallet communicates with the TokenWhitelist, the Controller, the TKN licence, and other ERC20 contracts. It should noted that the Consumer Contract Wallet only protects the ERC20 tokens supported by the TokenWhitelist in its Security Features, tokens not listed as available by the TokenWhitelist will not be secured by the Consumer Contract Wallet‘s daily spend limit; see(wallet inheritance digram).

controller.sol the Controller is used to perform tasks on behalf of Token Group Ltd. These tasks range from operational tasks, such as updating the token exchange rates via the Oracle, adding/removing tokens from the TokenWhitelist to signing 2FA functions on behalf of our users. The Controller contract implements a key hierarchy of: controllers used for operational tasks, admin used for administrative tasks, and the owner which is used to change out the admins; see(controller inheritance diagram).

gasProxy.sol the GasProxy can be used as a Controller to redeem gasTokens (e.g. GST2 or CHI) when executing Controller transactions. The depoloyed GasProxy contract should be added to the list of controllers in the Controller contract.

holder.sol is the TKN Holder contract, this is the Asset Contract as defined in the TokenCard whitepaper. This contract is used to hold 1% of all loads made onto TokenCards. The TokenWhitelist is used to define the set of tokens that are cash ‘n’ burnable (aka redeemable) by TKN holders who wish to burn their TKN. Users may burn their TKN on the TKN ERC20 contract which will call out to the burn method on the TKN Holder contract; see(holder inheritance diagram).

licence.sol is the TKN Licence contract, and it is used to take a 1% fee of all loads of the user’s TokenCard so that it can be sent to the TKN Holder contract. This contract is aware of the CryptoFloat where the remaining tokens are to be kept for Token Group Ltd for the loading of the TokenCards. It is also aware of the address of the TKN Holder contract that is used to back TKN. The TKN Licence contract has been created in a way to allow for a DAO to change some of its configured features, this is there to future proof the implementation; see (licence inheritance diagram).

oracle.sol is an exchange rate Oracle contract that gets exchange rates for a set of supported ERC20 tokens. Exchange rates are updated periodically by using the signed Crypto Compare API through the Provable oracle service. The list of tokens is managed by the TokenWhitelist, the Oracle merely updates exchange rates; see (oracle inheritance diagram).

tokenWhitelist.sol The list of tokens used in this system is managed in the TokenWhitelist. The Controller can be used to add and remove tokens from the TokenWhitelist, they also have the ability to set flags on the specific tokens, e.g. loadable (means that a token is loadable on the TokenCard) or redeemable (means that a token is redeemable in the TKN Holder contract); see (tokenWhitelist inheritance diagram).

walletCache.sol The WalletCache is a factory contract that is used to pre-deploy and cache the proxy contracts that make up the user’s Consumer Contract Wallets when network prices are low; see (walletCache inheritance diagram).

walletDeployer.sol The WalletDeployer contract accesses the WalletCache via ENS and allows the pre-cached wallets to be assigned new owners in a single contract call in order to satisfy requests for new Consumer Contract Wallets. This contract also has the ability to configure a contract with set security features, this will be used to migrate users between versions of the contract wallets; see (walletDeployer inheritance diagram).

Solidity code in the /contracts/internals/ folder

balanceable.sol is an inheritable contract that checks the ETH or ERC20 balance of an address.

burner.sol defines the Burner interface used for burning TKN for the cash n’ burn functionality.

bytesUtils.sol includes a set of utils for parsing bytes to things like ints and addresses.

controllable.sol is an inheritable contract that integrates with the list of controllers and provides control functionality to the child contract.

date.sol is a simple date parsing contract with a single method, used to parse out a comparable number from the date in an HTTP header.

ensResolvable.sol implements a inheritable contract that allows contracts to looked up others via ENS.

ownable.sol is an inheritable contract that provides owner authentication functionality to the owned contract.

parseIntScientific.sol provides floating point in scientific notation (e.g. e-5) parsing functionality. This has been built to support floating point scientific notation returned in JSON.

tokenWhitelistable.sol is an inheritable contract that interfaces with the tokenWhitelist.

transferrable.sol is an inheritable contract that allows for tokens or ETH to be transferred.

Solidity code in the /contracts/mocks/ folder

base64Exporter.sol is a mocked out version of a contract that pulls in the base64 encoder for unit testing purposes.

burnerToken.sol is version of the TKN contract used for testing the Cash n’ Burn functionality.

bytesUtilsExporter.sol used to export methods on the bytesUtils contract for testing purposes.

isValidSignatureExporter.sol used to export valid signatures for meta transaction testing.

nonCompliantToken.sol a version of a non-compliant ERC20 token, used to test the SafeERC20 stuff.

oraclize.sol is a mocked out version of the oraclize, this is for testing purposes only.

parseIntScientific-exporter.sol is a mocked out version of a contract that pulls in the parseIntScientific contract used to parse floating points that include scientific notation out of JSON.

token.sol is a partial compliant implementation of the ERC20 token standard used for testing and development purposes.

tokenWhitelistableExporter.sol exports the tokenWhitelist for testing purposes.

walletMock.sol exports the wallet that is now used by the proxy/library pattern so that it can be used for testing purposes.

Solidity code in the /contracts/externals/ folder

All of the third-party code we rely on can be found in this folder. The below table details the third-party code used and their licenses.

File License
Address.sol MIT
SafeMath.sol MIT
SafeERC20.sol MIT
base64.sol GPLv3
ENS Pubic Resolver BSD2
ENS Registry BSD2
strings.sol Apache v2
oraclizeAPI MIT
gnosis MultiSig GPLv3
zOS Upgradeability MIT

Deploying the contracts

We have an instance of the wallet-deployer, which is a factory contract, that is the official way of deploying a new instance of the Consumer Contract Wallet. The production instance of the wallet deployer factory contract can be found at the following ENS address: (wallet-deployer.v3.tokencard.eth) this works in conjunction with the wallet cache, which can be found at the following ENS address (wallet-cache.v3.tokencard.eth).

It should be noted that when creating a new instance of the Consumer Contract Wallet particular attention must be given to ensuring that the wallet is properly configured. It is particularly important that the wallet’s owner is no longer transaferable before the wallet is used in anger: arguements

Building contracts

To build all contracts and generate corresponding Go bindings:

./build.sh

Running contract unit tests

  • go version >1.11 is required.
  • go modules (experimental in go 1.11) are needed. export GO111MODULE=on
go modules download

To test the contracts using the go command run:

go test -v ./test/...

To test the contracts using the ginkgo command run:

SILENT=true ginkgo -nodes=16 -r -p ./test/...

Running validation tools

To run all validation tools locally using Docker run:

./tools/run-all.sh

To run a specific validation tool, use the provided scripts:

./tools/prettier/format.sh ./tools/slither/flatten.sh ./tools/slither/slither.sh ./tools/echidna/echidna.sh ./tools/mythril/mythril.sh ./tools/manticore/manticore.sh

To generate the inheritance graphs

docker run -v /path/contracts:/contracts -it trailofbits/eth-security-toolbox:latest solc-select 0.5.17 cd /contracts sudo apt-get update sudo apt install xdot slither contracts/wallet.sol --print inheritance-graph dot contracts.dot -Tpng -o ./wallet.inheritance.png

Resources

🎮 Discord 🗞️Blog 👽 Reddit 🕸️ Website 🐦 Twitter

The Consumer Contract Wallet – Version 3.4.1

这个存储库包含了在EVM中执行所需的智能合约,这些合约是用Solidity编写的。

我们致力于在以太坊eth上建立非托管银行业务替代方案,这些合同定义了我们与用户的关系。

巨石卡是全球首张VISA借记卡的非托管卡。消费者合同钱包允许人们持有自己的资产,同时能够无缝地将资金转移到VISA借记卡上。用户自己向TKN持有人合同发送1%的整体式卡负载。这是用来支持公益金(又称资产合同)。这种链上基础设施的目的是在现实世界中使用加密时提供最无缝的用户体验,同时保持分散的地位。

High Level Architecture Security Features Solidity Code Running Contract Tests Resources

Overview

本存储库中智能合约中编码的功能旨在帮助用户保护他们的代币,方法是将代币保存在自己的合约钱包内,实现我们消费者合约钱包中定义的逻辑。合同钱包的用户需要根据自己的喜好配置钱包。消费者合同钱包中定义的逻辑是为了在用户的私钥被泄露的情况下限制用户丢失代币的风险。

我们认为,在采用和使用分散财务时面临三个主要问题:

  • The issue that users with compromised private keys could end up losing all of their assets.
  • The issue that people are generally not good at keeping digital secrets safe, the potential loss of private keys.
  • The UX of decentralised finances and how they interplay into real-world payments.

这是消费者合同钱包的3.3.1版,使用库/代理模式部署此智能合约。这种模式主要用于(可升级的智能合约),但也可用于提供链上的效率。所有用户都会得到一个代理合同,该合同将逻辑外包给一个中心库合同。消费者合同钱包使用OpenZeppelin在其套件(可升级合同)中开发的代理合同。需要注意的是,消费者合同钱包建立在想要构建可升级智能合约的开发者使用的代理合约之上,这个版本的合约钱包本身是不可升级的。用户仍然需要在合同钱包的不同版本之间进行迁移,以获得新功能的好处。

消费者合同钱包通过限制用户在私钥被泄露的情况下遭受盗窃来保护他们。此版本还将“批量元交易”添加到合同钱包的功能列表中。批处理的元交易非常灵活,可以从等式中删除gas,或者在任何ERC20代币中大致支付gas。通过分批处理元事务,我们将能够利用以太坊eth上智能合约调用的可组合性,构建更具吸引力的用户体验。

每个用户部署自己的代理合同,即他们的合同钱包,使用中定义的逻辑(钱包.sol)它又与令牌白名单交互(令牌白名单.sol)获取令牌汇率以强制执行用户定义的每日开支限制。令牌白名单契约中的汇率使用汇率Oracle定期更新(甲骨文.sol)它建立在以太坊ethAPI和CryptoCompare的API之上。

消费者合同钱包中的服务发现通过使用以太坊eth名称服务(ENS)来执行。例如,ENS用于解析令牌白名单契约的位置,以及解析控制器的位置(控制器.sol)合同。代币白名单是代币及其汇率的列表,定义了用户钱包内受保护的代币集。它还确定哪些令牌可以用来将菲亚特加载到用户的巨石卡上。通过将资产发送到(许可证.sol)该合同收取1%的费用并将其添加到(电磁阀保持架)合同。发送给持有人合同的代币由(TKN ERC-20合同)与TKN持有人合同“现金‘n’可燃烧”。此控制器合同仅用于管理目的,请放心,这是没有权限使用用户的资金。控制器用于在Oracle和令牌白名单上执行2FA功能以及管理任务。

High-level Architecture

The Consumer Contract Wallet - Version 3.4.1 - 消费者合同钱包-版本3.4.1

Assumptions

  • Every user will have their own Public and Private key pair, aka the Owner Address.
  • Users SHOULD NEVER have to share the Private Key of their Owner Address with anyone.
  • There are a number of different “pots of tokens” for a given user:
    • The user’s entire ETH and ERC20 token assets stored within the Consumer Contract Wallet.
    • An amount of ETH used to pay for the gas – Gas Tank. The Gas Tank is a representation of the ETH on the user’s Owner Address. It should be noted that this ETH is NOT protected by the security features in the Consumer Contract Wallet as it resides outside of the Smart Contract. Note: in the current version (v3) meta-transactions are also supported i.e. the users can send trasnactions without having to top-up their Gas Tank. The way it works is the following: they sign the transsaction with their private key, a controller broadcasts it, the signature is validated by their contract and the original transaction is executed consecutively. The Gas Tank has been kept mainly for convenience and is gonna be removed entirely in the upcoming version.

Requirements

  • This Owner Address will own all of the user’s Smart Contracts and will be referred to as the Owner, this is sometimes referred to as an Externally Owned Address (EOA)
  • The Controller – Is a key hierarchy of administrative addresses, owned and operated by Token Group Ltd. These are used to provide convenience to our users.
  • The Consumer Contract Wallet needs to allow its Owner to configure how they wish to secure their tokens in their wallet.
  • There needs to be a convenient way to “top-up” the amount of ETH that lives on our user’s Owner Address aka Gas Tank via the Smart Contracts
  • The wallet’s design is intended to be as decentralised as possible. This will be achieved by eliminating access to user assets by third-parties and minimising reliance of third-party infrastructure in running the Consumer Contract Wallet.
  • Must help user protect their funds by minimising the risk in the event of their Owner Address‘s private key being compromised.
  • Provide the best UX possible.

Security Features

<The Consumer Contract Wallet - Version 3.4.1>

  • A Whitelist of Addresses – akin to a whitelist of payees in a banking application, this whitelist should be configured with a list of trusted addresses for each Owner of the Consumer Contract Wallet.
  • Daily Spending Limit – denominated in ETH. This is used to define how much can a user transfer in a given day if transferring assets to addresses outside their Whitelist.
  • Daily Gas Tank Top-up Limit – (Gas Tank) top-up daily limit denominated in ETH. This is used to define the daily limit of ETH that can be sent from a user’s Consumer Contract Wallet to their Address; this ETH is what is used to pay the network for gas.
  • Daily Card Load Limit – (Card Load Limit) card loading daily limit denominated in USD (technically speaking in a stablecoin like USDC). This is used to define the daily limit of tokens or ETH that can be sent from a user’s Consumer Contract Wallet for loading of the user’s TokenCard. This is currently set to 10K USD.

Configuration

为了帮助用户在私钥被泄露的情况下保护其令牌,我们提供以下安全功能:

  • via Constructor: Upon deployment of a new Consumer Contract Wallet the above security features are configured: a) by passing the desired value for the Daily Spending Limit to the constructor b2) by setting default values for the Daily Gas Tank Top-up Limit and Daily Card Load Limit, when deploying the Consumer Contract Wallet smart contract the to the Ethereum network. This is how the values are set when deploying a new instance of the Consumer Contract Wallet.
  • via a 1-time write pattern: Aside from default values and values passed in via the Constructor the user may do a 1-time write to the aforementioned Security Features. These allow the Address to change the values that power the security features. It is advised that users of the Consumer Contract Wallet set their security settings so that they can not longer be tampered with in the event that a user’s private key is compromised. Users should set these values once, otherwise an attacker would be able to configure their Smart Contract.
  • via a 2FA pattern: Where a user can submitChange a new value for one of the Security Features, then one of the Controller addresses needs to either OK the value change or not. It should be noted that due to the nature of the user AddressWhitelist where a user may add or remove items from their whitelist via the 2FA pattern, only one pending change to the user’s address whitelist can be in flight at a given point in time.

Naming convention

有三种方法来配置消费者合同钱包:

  • Contracts – should be Nouns
  • Functions – should be Verbs
  • Ables – Smart Contracts that are meant to be inherited and not standalone, i.e. they are Mixins, Snippets, Decorators …
  • Private contract scoped variables – all start with an underscore _
  • Private / internal functions – all start with an underscore _
  • Constructor parameters – all start with an underscore _ and end in one too, e.g. _ens_ this is to avoid shadowing
  • Function parameters – all start with an underscore _
  • Local variables – to functions should start without an underscore
  • Public contract scoped variables – should start without an underscore
  • Public functions – should start without an underscore
  • Crud functions – when there exist multiple actions on the same variable we will use the suffix to illustrate the action, for example : dailySpendLimitSet, and dailySpendLimitUpdate

Solidity code in the /contracts/ folder

本节详细介绍了此代码库中采用的命名约定:

应该注意的是,此代码库大量使用继承。

钱包.sol是图书馆合同,它定义了消费者合同钱包的业务逻辑。这个库是用来保护用户资金的。钱包与令牌白名单、控制器、TKN许可证和其他ERC20合同通信。需要注意的是,消费者合同钱包在其安全功能上仅保护代币白名单支持的ERC20代币,未被代币白名单列为可用的代币将不受消费者合同钱包每日消费限额的保护;参见(钱包继承图)。

控制器.sol控制器用于代表Token Group Ltd执行任务。这些任务包括操作任务,例如通过Oracle更新令牌汇率、从令牌白名单添加/删除令牌到代表我们的用户签署2FA功能。控制器契约实现了一个键层次结构:用于操作任务的控制器、用于管理任务的管理员和用于更改管理员的所有者;请参阅(控制器继承图)。

加斯普罗西·索尔在执行控制器事务时,GasProxy可以用作控制器来赎回gasTokens(例如GST2或CHI)。撤销的GasProxy合同应添加到控制者合同中的控制者列表中。

电磁阀保持架是TKN持有人合同,这是代币卡白皮书中定义的资产合同。已使用%1的合约卡装载到该卡上。TokenWhitelist用于定义希望烧掉其TKN的TKN持有人可以使用现金“n”燃烧(也称为可赎回)的代币集。用户可以在TKN ERC20合同上刻录其TKN,该合同将调用TKN持有人合同上的刻录方法;请参见(持有者继承图)。

许可证.sol是TKN许可合同,用于收取用户代币卡所有负载的1%费用,以便将其发送给TKN持有人合同。本合同了解加密浮点数,剩余的代币将保留给代币集团有限公司,以便装载代币卡。它还知道用于支持TKN的TKN持有人合同的地址。TKN许可合同的创建方式允许DAO更改其配置的某些特性,这是为了将来验证实现;请参见(许可证继承图)。

甲骨文.sol是一个汇率Oracle合约,它获取一组受支持的ERC20代币的汇率。通过可证明的oracle服务,使用签名加密比较API定期更新汇率。代币列表由代币白名单管理,甲骨文只更新汇率;参见(甲骨文继承图)。

令牌白名单.sol此系统中使用的令牌列表在令牌白名单中管理。控制器可用于在令牌白名单中添加和删除令牌,它们还可以在特定令牌上设置标志,例如可加载(表示令牌可在令牌卡上加载)或可赎回(表示令牌可在TKN持有人合同中赎回);请参阅(令牌白名单继承图)。

walletCache.solWalletCache是一个工厂合同,用于在网络价格较低时预先部署和缓存组成用户消费合同钱包的代理合同;请参阅(WalletCache继承图)。

Solidity code in the /contracts/internals/ folder

walletDeployer.solWalletDeployer合同通过ENS访问WalletCache,并允许在单个合同调用中为预缓存的钱包分配新的所有者,以满足对新的消费者合同钱包的请求。此合约还可以配置具有设置安全功能的合约,这将用于在合约钱包的不同版本之间迁移用户;请参阅(walletDeployer继承关系图)。

可平衡.sol是一个可继承的契约,用于检查地址的ETH或ERC20余额。

燃烧器.sol定义用于为cash n’burn功能刻录TKN的Burner接口。

字节实用程序.sol包含一组用于将字节解析为int和address之类的内容的实用程序。

可控.sol是一个可继承的协定,它与控制器列表集成,并为子协定提供控制功能。

日期.sol是一个具有单个方法的简单日期解析协定,用于从HTTP报头中的日期解析出一个可比较的数字。

可解析.sol实现一个可继承的契约,允许契约通过ENS查找其他契约。

可拥有.sol是一个可继承的协定,它为所属协定提供所有者身份验证功能。

解析科学.sol提供科学记数法(例如e-5)中的浮点解析功能。这是为了支持JSON中返回的浮点科学表示法而构建的。

令牌白名单.sol是与令牌白名单接口的可继承协定。

Solidity code in the /contracts/mocks/ folder

可转移.sol是一个允许令牌或ETH被传输的可继承契约。

base64出口商.sol是契约的模拟版本,它将base64编码器用于单元测试目的。

伯恩托肯.sol是用于测试Cash n’Burn功能的TKN合同版本。

bytesUtilsExporter.sol用于导出bytesUtils合同上的方法以进行测试。

isValidSignatureExporter.sol用于exp

oraclize.sol is a mocked out version of the oraclize, this is for testing purposes only.

parseIntScientific-exporter.sol is a mocked out version of a contract that pulls in the parseIntScientific contract used to parse floating points that include scientific notation out of JSON.

token.sol is a partial compliant implementation of the ERC20 token standard used for testing and development purposes.

tokenWhitelistableExporter.sol exports the tokenWhitelist for testing purposes.

walletMock.sol exports the wallet that is now used by the proxy/library pattern so that it can be used for testing purposes.

Solidity code in the /contracts/externals/ folder

All of the third-party code we rely on can be found in this folder. The below table details the third-party code used and their licenses.

File License
Address.sol MIT
SafeMath.sol MIT
SafeERC20.sol MIT
base64.sol GPLv3
ENS Pubic Resolver BSD2
ENS Registry BSD2
strings.sol Apache v2
oraclizeAPI MIT
gnosis MultiSig GPLv3
zOS Upgradeability MIT

Deploying the contracts

We have an instance of the wallet-deployer, which is a factory contract, that is the official way of deploying a new instance of the Consumer Contract Wallet. The production instance of the wallet deployer factory contract can be found at the following ENS address: (wallet-deployer.v3.tokencard.eth) this works in conjunction with the wallet cache, which can be found at the following ENS address (wallet-cache.v3.tokencard.eth).

It should be noted that when creating a new instance of the Consumer Contract Wallet particular attention must be given to ensuring that the wallet is properly configured. It is particularly important that the wallet’s owner is no longer transaferable before the wallet is used in anger: arguements

Building contracts

To build all contracts and generate corresponding Go bindings:

./build.sh

Running contract unit tests

  • go version >1.11 is required.
  • go modules (experimental in go 1.11) are needed. export GO111MODULE=on
go modules download

To test the contracts using the go command run:

go test -v ./test/...

To test the contracts using the ginkgo command run:

SILENT=true ginkgo -nodes=16 -r -p ./test/...

Running validation tools

To run all validation tools locally using Docker run:

./tools/run-all.sh

To run a specific validation tool, use the provided scripts:

./tools/prettier/format.sh ./tools/slither/flatten.sh ./tools/slither/slither.sh ./tools/echidna/echidna.sh ./tools/mythril/mythril.sh ./tools/manticore/manticore.sh

To generate the inheritance graphs

docker run -v /path/contracts:/contracts -it trailofbits/eth-security-toolbox:latest solc-select 0.5.17 cd /contracts sudo apt-get update sudo apt install xdot slither contracts/wallet.sol --print inheritance-graph dot contracts.dot -Tpng -o ./wallet.inheritance.png

Resources

🎮 Discord 🗞️Blog 👽 Reddit 🕸️ Website 🐦 Twitter

部分转自网络,侵权联系删除区块链源码网

www.interchains.cc

https://www.interchains.cc/17012.html

区块链毕设网(www.interchains.cc)全网最靠谱的原创区块链毕设代做网站 部分资料来自网络,侵权联系删除! 最全最大的区块链源码站 !
区块链知识分享网, 以太坊dapp资源网, 区块链教程, fabric教程下载, 区块链书籍下载, 区块链资料下载, 区块链视频教程下载, 区块链基础教程, 区块链入门教程, 区块链资源 » The Consumer Contract Wallet – Version 3.4.1 – 消费者合同钱包-版本3.4.1区块链毕设代写

提供最优质的资源集合

立即查看 了解详情