Remove code in preparation for v5.0 (#4258)
Co-authored-by: Ernesto García <ernestognw@gmail.com> Co-authored-by: Francisco <fg@frang.io>
This commit is contained in:
Hadrien Croubois
GitHub
@ -11,14 +11,11 @@
|
||||
** xref:erc20.adoc[ERC20]
|
||||
*** xref:erc20-supply.adoc[Creating Supply]
|
||||
** xref:erc721.adoc[ERC721]
|
||||
** xref:erc777.adoc[ERC777]
|
||||
** xref:erc1155.adoc[ERC1155]
|
||||
** xref:erc4626.adoc[ERC4626]
|
||||
|
||||
* xref:governance.adoc[Governance]
|
||||
|
||||
* xref:crosschain.adoc[Crosschain]
|
||||
|
||||
* xref:utilities.adoc[Utilities]
|
||||
|
||||
* xref:subgraphs::index.adoc[Subgraphs]
|
||||
|
||||
@ -1,210 +0,0 @@
|
||||
= Adding cross-chain support to contracts
|
||||
|
||||
If your contract is targeting to be used in the context of multichain operations, you may need specific tools to identify and process these cross-chain operations.
|
||||
|
||||
OpenZeppelin provides the xref:api:crosschain.adoc#CrossChainEnabled[`CrossChainEnabled`] abstract contract, that includes dedicated internal functions.
|
||||
|
||||
In this guide, we will go through an example use case: _how to build an upgradeable & mintable ERC20 token controlled by a governor present on a foreign chain_.
|
||||
|
||||
== Starting point, our ERC20 contract
|
||||
|
||||
Let's start with a small ERC20 contract, that we bootstrapped using the https://wizard.openzeppelin.com/[OpenZeppelin Contracts Wizard], and extended with an owner that has the ability to mint. Note that for demonstration purposes we have not used the built-in `Ownable` contract.
|
||||
|
||||
[source,solidity]
|
||||
----
|
||||
// SPDX-License-Identifier: MIT
|
||||
pragma solidity ^0.8.4;
|
||||
|
||||
import "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol";
|
||||
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
|
||||
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
|
||||
|
||||
contract MyToken is Initializable, ERC20Upgradeable, UUPSUpgradeable {
|
||||
address public owner;
|
||||
|
||||
modifier onlyOwner() {
|
||||
require(owner == _msgSender(), "Not authorized");
|
||||
_;
|
||||
}
|
||||
|
||||
/// @custom:oz-upgrades-unsafe-allow constructor
|
||||
constructor() initializer {}
|
||||
|
||||
function initialize(address initialOwner) initializer public {
|
||||
__ERC20_init("MyToken", "MTK");
|
||||
__UUPSUpgradeable_init();
|
||||
|
||||
owner = initialOwner;
|
||||
}
|
||||
|
||||
function mint(address to, uint256 amount) public onlyOwner {
|
||||
_mint(to, amount);
|
||||
}
|
||||
|
||||
function _authorizeUpgrade(address newImplementation) internal override onlyOwner {
|
||||
}
|
||||
}
|
||||
----
|
||||
|
||||
This token is mintable and upgradeable by the owner of the contract.
|
||||
|
||||
== Preparing our contract for cross-chain operations.
|
||||
|
||||
Let's now imagine that this contract is going to live on one chain, but we want the minting and the upgrading to be performed by a xref:governance.adoc[`governor`] contract on another chain.
|
||||
|
||||
For example, we could have our token on xDai, with our governor on mainnet, or we could have our token on mainnet, with our governor on optimism
|
||||
|
||||
In order to do that, we will start by adding xref:api:crosschain.adoc#CrossChainEnabled[`CrossChainEnabled`] to our contract. You will notice that the contract is now abstract. This is because `CrossChainEnabled` is an abstract contract: it is not tied to any particular chain and it deals with cross-chain interactions in an abstract way. This is what enables us to easily reuse the code for different chains. We will specialize it later by inheriting from a chain-specific implementation of the abstraction.
|
||||
|
||||
```diff
|
||||
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
|
||||
+import "@openzeppelin/contracts-upgradeable/crosschain/CrossChainEnabled.sol";
|
||||
|
||||
-contract MyToken is Initializable, ERC20Upgradeable, UUPSUpgradeable {
|
||||
+abstract contract MyTokenCrossChain is Initializable, ERC20Upgradeable, UUPSUpgradeable, CrossChainEnabled {
|
||||
```
|
||||
|
||||
Once that is done, we can use the `onlyCrossChainSender` modifier, provided by `CrossChainEnabled` in order to protect the minting and upgrading operations.
|
||||
|
||||
```diff
|
||||
- function mint(address to, uint256 amount) public onlyOwner {
|
||||
+ function mint(address to, uint256 amount) public onlyCrossChainSender(owner) {
|
||||
|
||||
- function _authorizeUpgrade(address newImplementation) internal override onlyOwner {
|
||||
+ function _authorizeUpgrade(address newImplementation) internal override onlyCrossChainSender(owner) {
|
||||
```
|
||||
|
||||
This change will effectively restrict the mint and upgrade operations to the `owner` on the remote chain.
|
||||
|
||||
== Specializing for a specific chain
|
||||
|
||||
Once the abstract cross-chain version of our token is ready we can easily specialize it for the chain we want, or more precisely for the bridge system that we want to rely on.
|
||||
|
||||
This is done using one of the many `CrossChainEnabled` implementations.
|
||||
|
||||
For example, if our token is on xDai, and our governor on mainnet, we can use the https://docs.tokenbridge.net/amb-bridge/about-amb-bridge[AMB] bridge available on xDai at https://blockscout.com/xdai/mainnet/address/0x75Df5AF045d91108662D8080fD1FEFAd6aA0bb59[0x75Df5AF045d91108662D8080fD1FEFAd6aA0bb59]
|
||||
|
||||
[source,solidity]
|
||||
----
|
||||
[...]
|
||||
|
||||
import "@openzeppelin/contracts-upgradeable/crosschain/amb/CrossChainEnabledAMB.sol";
|
||||
|
||||
contract MyTokenXDAI is
|
||||
MyTokenCrossChain,
|
||||
CrossChainEnabledAMB(0x75Df5AF045d91108662D8080fD1FEFAd6aA0bb59)
|
||||
{}
|
||||
----
|
||||
|
||||
If the token is on Ethereum mainnet, and our governor on Optimism, we use the Optimism https://community.optimism.io/docs/protocol/protocol-2.0/#l1crossdomainmessenger[CrossDomainMessenger] available on mainnet at https://etherscan.io/address/0x25ace71c97B33Cc4729CF772ae268934F7ab5fA1[0x25ace71c97B33Cc4729CF772ae268934F7ab5fA1].
|
||||
|
||||
[source,solidity]
|
||||
----
|
||||
[...]
|
||||
|
||||
import "@openzeppelin/contracts-upgradeable/crosschain/optimismCrossChainEnabledOptimism.sol";
|
||||
|
||||
contract MyTokenOptimism is
|
||||
MyTokenCrossChain,
|
||||
CrossChainEnabledOptimism(0x25ace71c97B33Cc4729CF772ae268934F7ab5fA1)
|
||||
{}
|
||||
----
|
||||
|
||||
== Mixing cross domain addresses is dangerous
|
||||
|
||||
When designing a contract with cross-chain support, it is essential to understand possible fallbacks and the security assumption that are being made.
|
||||
|
||||
In this guide, we are particularly focusing on restricting access to a specific caller. This is usually done (as shown above) using `msg.sender` or `_msgSender()`. However, when going cross-chain, it is not just that simple. Even without considering possible bridge issues, it is important to keep in mind that the same address can correspond to very different entities when considering a multi-chain space. EOA wallets can only execute operations if the wallet's private-key signs the transaction. To our knowledge this is the case in all EVM chains, so a cross-chain message coming from such a wallet is arguably equivalent to a non-cross-chain message by the same wallet. The situation is however very different for smart contracts.
|
||||
|
||||
Due to the way smart contract addresses are computed, and the fact that smart contracts on different chains live independent lives, you could have two very different contracts live at the same address on different chains. You could imagine two multisig wallets with different signers using the same address on different chains. You could also see a very basic smart wallet live on one chain at the same address as a full-fledged governor on another chain. Therefore, you should be careful that whenever you give permissions to a specific address, you control with chain this address can act from.
|
||||
|
||||
== Going further with access control
|
||||
|
||||
In the previous example, we have both an `onlyOwner()` modifier and the `onlyCrossChainSender(owner)` mechanism. We didn't use the xref:access-control.adoc#ownership-and-ownable[`Ownable`] pattern because the ownership transfer mechanism in includes is not designed to work with the owner being a cross-chain entity. Unlike xref:access-control.adoc#ownership-and-ownable[`Ownable`], xref:access-control.adoc#role-based-access-control[`AccessControl`] is more effective at capturing the nuances and can effectively be used to build cross-chain-aware contracts.
|
||||
|
||||
Using xref:api:access.adoc#AccessControlCrossChain[`AccessControlCrossChain`] includes both the xref:api:access.adoc#AccessControl[`AccessControl`] core and the xref:api:crosschain.adoc#CrossChainEnabled[`CrossChainEnabled`] abstraction. It also includes some binding to make role management compatible with cross-chain operations.
|
||||
|
||||
In the case of the `mint` function, the caller must have the `MINTER_ROLE` when the call originates from the same chain. If the caller is on a remote chain, then the caller should not have the `MINTER_ROLE`, but the "aliased" version (`MINTER_ROLE ^ CROSSCHAIN_ALIAS`). This mitigates the danger described in the previous section by strictly separating local accounts from remote accounts from a different chain. See the xref:api:access.adoc#AccessControlCrossChain[`AccessControlCrossChain`] documentation for more details.
|
||||
|
||||
|
||||
```diff
|
||||
import "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol";
|
||||
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
|
||||
+import "@openzeppelin/contracts-upgradeable/access/AccessControlCrossChainUpgradeable.sol";
|
||||
|
||||
-abstract contract MyTokenCrossChain is Initializable, ERC20Upgradeable, UUPSUpgradeable, CrossChainEnabled {
|
||||
+abstract contract MyTokenCrossChain is Initializable, ERC20Upgradeable, UUPSUpgradeable, AccessControlCrossChainUpgradeable {
|
||||
|
||||
- address public owner;
|
||||
- modifier onlyOwner() {
|
||||
- require(owner == _msgSender(), "Not authorized");
|
||||
- _;
|
||||
- }
|
||||
|
||||
+ bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
|
||||
+ bytes32 public constant UPGRADER_ROLE = keccak256("UPGRADER_ROLE");
|
||||
|
||||
function initialize(address initialOwner) initializer public {
|
||||
__ERC20_init("MyToken", "MTK");
|
||||
__UUPSUpgradeable_init();
|
||||
+ __AccessControl_init();
|
||||
+ _grantRole(_crossChainRoleAlias(DEFAULT_ADMIN_ROLE), initialOwner); // initialOwner is on a remote chain
|
||||
- owner = initialOwner;
|
||||
}
|
||||
|
||||
- function mint(address to, uint256 amount) public onlyCrossChainSender(owner) {
|
||||
+ function mint(address to, uint256 amount) public onlyRole(MINTER_ROLE) {
|
||||
|
||||
- function _authorizeUpgrade(address newImplementation) internal override onlyCrossChainSender(owner) {
|
||||
+ function _authorizeUpgrade(address newImplementation) internal override onlyRole(UPGRADER_ROLE) {
|
||||
```
|
||||
|
||||
This results in the following, final, code:
|
||||
|
||||
[source,solidity]
|
||||
----
|
||||
// SPDX-License-Identifier: MIT
|
||||
pragma solidity ^0.8.4;
|
||||
|
||||
import "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol";
|
||||
import "@openzeppelin/contracts-upgradeable/access/AccessControlCrossChainUpgradeable.sol";
|
||||
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
|
||||
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
|
||||
|
||||
abstract contract MyTokenCrossChain is Initializable, ERC20Upgradeable, AccessControlCrossChainUpgradeable, UUPSUpgradeable {
|
||||
bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
|
||||
bytes32 public constant UPGRADER_ROLE = keccak256("UPGRADER_ROLE");
|
||||
|
||||
/// @custom:oz-upgrades-unsafe-allow constructor
|
||||
constructor() initializer {}
|
||||
|
||||
function initialize(address initialOwner) initializer public {
|
||||
__ERC20_init("MyToken", "MTK");
|
||||
__AccessControl_init();
|
||||
__UUPSUpgradeable_init();
|
||||
|
||||
_grantRole(_crossChainRoleAlias(DEFAULT_ADMIN_ROLE), initialOwner); // initialOwner is on a remote chain
|
||||
}
|
||||
|
||||
function mint(address to, uint256 amount) public onlyRole(MINTER_ROLE) {
|
||||
_mint(to, amount);
|
||||
}
|
||||
|
||||
function _authorizeUpgrade(address newImplementation) internal onlyRole(UPGRADER_ROLE) override {
|
||||
}
|
||||
}
|
||||
|
||||
import "@openzeppelin/contracts-upgradeable/crosschain/amb/CrossChainEnabledAMB.sol";
|
||||
|
||||
contract MyTokenXDAI is
|
||||
MyTokenCrossChain,
|
||||
CrossChainEnabledAMB(0x75Df5AF045d91108662D8080fD1FEFAd6aA0bb59)
|
||||
{}
|
||||
|
||||
import "@openzeppelin/contracts-upgradeable/crosschain/optimismCrossChainEnabledOptimism.sol";
|
||||
|
||||
contract MyTokenOptimism is
|
||||
MyTokenCrossChain,
|
||||
CrossChainEnabledOptimism(0x25ace71c97B33Cc4729CF772ae268934F7ab5fA1)
|
||||
{}
|
||||
----
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
ERC1155 is a novel token standard that aims to take the best from previous standards to create a xref:tokens.adoc#different-kinds-of-tokens[*fungibility-agnostic*] and *gas-efficient* xref:tokens.adoc#but_first_coffee_a_primer_on_token_contracts[token contract].
|
||||
|
||||
TIP: ERC1155 draws ideas from all of xref:erc20.adoc[ERC20], xref:erc721.adoc[ERC721], and xref:erc777.adoc[ERC777]. If you're unfamiliar with those standards, head to their guides before moving on.
|
||||
TIP: ERC1155 draws ideas from all of xref:erc20.adoc[ERC20], xref:erc721.adoc[ERC721], and https://eips.ethereum.org/EIPS/eip-777[ERC777]. If you're unfamiliar with those standards, head to their guides before moving on.
|
||||
|
||||
[[multi-token-standard]]
|
||||
== Multi Token Standard
|
||||
@ -22,9 +22,9 @@ In the spirit of the standard, we've also included batch operations in the non-s
|
||||
|
||||
== Constructing an ERC1155 Token Contract
|
||||
|
||||
We'll use ERC1155 to track multiple items in our game, which will each have their own unique attributes. We mint all items to the deployer of the contract, which we can later transfer to players. Players are free to keep their tokens or trade them with other people as they see fit, as they would any other asset on the blockchain!
|
||||
We'll use ERC1155 to track multiple items in our game, which will each have their own unique attributes. We mint all items to the deployer of the contract, which we can later transfer to players. Players are free to keep their tokens or trade them with other people as they see fit, as they would any other asset on the blockchain!
|
||||
|
||||
For simplicity, we will mint all items in the constructor, but you could add minting functionality to the contract to mint on demand to players.
|
||||
For simplicity, we will mint all items in the constructor, but you could add minting functionality to the contract to mint on demand to players.
|
||||
|
||||
TIP: For an overview of minting mechanisms, check out xref:erc20-supply.adoc[Creating ERC20 Supply].
|
||||
|
||||
@ -112,7 +112,7 @@ The JSON document for token ID 2 might look something like:
|
||||
|
||||
For more information about the metadata JSON Schema, check out the https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1155.md#erc-1155-metadata-uri-json-schema[ERC-1155 Metadata URI JSON Schema].
|
||||
|
||||
NOTE: You'll notice that the item's information is included in the metadata, but that information isn't on-chain! So a game developer could change the underlying metadata, changing the rules of the game!
|
||||
NOTE: You'll notice that the item's information is included in the metadata, but that information isn't on-chain! So a game developer could change the underlying metadata, changing the rules of the game!
|
||||
|
||||
TIP: If you'd like to put all item information on-chain, you can extend ERC721 to do so (though it will be rather costly) by providing a xref:utilities.adoc#base64[`Base64`] Data URI with the JSON schema encoded. You could also leverage IPFS to store the URI information, but these techniques are out of the scope of this overview guide
|
||||
|
||||
|
||||
@ -1,75 +0,0 @@
|
||||
= ERC777
|
||||
|
||||
CAUTION: As of v4.9, OpenZeppelin's implementation of ERC-777 is deprecated and will be removed in the next major release.
|
||||
|
||||
Like xref:erc20.adoc[ERC20], ERC777 is a standard for xref:tokens.adoc#different-kinds-of-tokens[_fungible_ tokens], and is focused around allowing more complex interactions when trading tokens. More generally, it brings tokens and Ether closer together by providing the equivalent of a `msg.value` field, but for tokens.
|
||||
|
||||
The standard also brings multiple quality-of-life improvements, such as getting rid of the confusion around `decimals`, minting and burning with proper events, among others, but its killer feature is *receive hooks*. A hook is simply a function in a contract that is called when tokens are sent to it, meaning *accounts and contracts can react to receiving tokens*.
|
||||
|
||||
This enables a lot of interesting use cases, including atomic purchases using tokens (no need to do `approve` and `transferFrom` in two separate transactions), rejecting reception of tokens (by reverting on the hook call), redirecting the received tokens to other addresses (similarly to how xref:api:payment#PaymentSplitter[`PaymentSplitter`] does it), among many others.
|
||||
|
||||
Furthermore, since contracts are required to implement these hooks in order to receive tokens, _no tokens can get stuck in a contract that is unaware of the ERC777 protocol_, as has happened countless times when using ERC20s.
|
||||
|
||||
== What If I Already Use ERC20?
|
||||
|
||||
The standard has you covered! The ERC777 standard is *backwards compatible with ERC20*, meaning you can interact with these tokens as if they were ERC20, using the standard functions, while still getting all of the niceties, including send hooks. See the https://eips.ethereum.org/EIPS/eip-777#backward-compatibility[EIP's Backwards Compatibility section] to learn more.
|
||||
|
||||
== Constructing an ERC777 Token Contract
|
||||
|
||||
We will replicate the `GLD` example of the xref:erc20.adoc#constructing-an-erc20-token-contract[ERC20 guide], this time using ERC777. As always, check out the xref:api:token/ERC777.adoc[`API reference`] to learn more about the details of each function.
|
||||
|
||||
[source,solidity]
|
||||
----
|
||||
// contracts/GLDToken.sol
|
||||
// SPDX-License-Identifier: MIT
|
||||
pragma solidity ^0.8.0;
|
||||
|
||||
import "@openzeppelin/contracts/token/ERC777/ERC777.sol";
|
||||
|
||||
contract GLDToken is ERC777 {
|
||||
constructor(uint256 initialSupply, address[] memory defaultOperators)
|
||||
ERC777("Gold", "GLD", defaultOperators)
|
||||
{
|
||||
_mint(msg.sender, initialSupply, "", "");
|
||||
}
|
||||
}
|
||||
----
|
||||
|
||||
In this case, we'll be extending from the xref:api:token/ERC777.adoc#ERC777[`ERC777`] contract, which provides an implementation with compatibility support for ERC20. The API is quite similar to that of xref:api:token/ERC777.adoc#ERC777[`ERC777`], and we'll once again make use of xref:api:token/ERC777.adoc#ERC777-_mint-address-address-uint256-bytes-bytes-[`_mint`] to assign the `initialSupply` to the deployer account. Unlike xref:api:token/ERC20.adoc#ERC20-_mint-address-uint256-[ERC20's `_mint`], this one includes some extra parameters, but you can safely ignore those for now.
|
||||
|
||||
You'll notice both xref:api:token/ERC777.adoc#IERC777-name--[`name`] and xref:api:token/ERC777.adoc#IERC777-symbol--[`symbol`] are assigned, but not xref:api:token/ERC777.adoc#ERC777-decimals--[`decimals`]. The ERC777 specification makes it mandatory to include support for these functions (unlike ERC20, where it is optional and we had to include xref:api:token/ERC20.adoc#ERC20Detailed[`ERC20Detailed`]), but also mandates that `decimals` always returns a fixed value of `18`, so there's no need to set it ourselves. For a review of ``decimals``'s role and importance, refer back to our xref:erc20.adoc#a-note-on-decimals[ERC20 guide].
|
||||
|
||||
Finally, we'll need to set the xref:api:token/ERC777.adoc#IERC777-defaultOperators--[`defaultOperators`]: special accounts (usually other smart contracts) that will be able to transfer tokens on behalf of their holders. If you're not planning on using operators in your token, you can simply pass an empty array. _Stay tuned for an upcoming in-depth guide on ERC777 operators!_
|
||||
|
||||
That's it for a basic token contract! We can now deploy it, and use the same xref:api:token/ERC777.adoc#IERC777-balanceOf-address-[`balanceOf`] method to query the deployer's balance:
|
||||
|
||||
[source,javascript]
|
||||
----
|
||||
> GLDToken.balanceOf(deployerAddress)
|
||||
1000
|
||||
----
|
||||
|
||||
To move tokens from one account to another, we can use both xref:api:token/ERC777.adoc#ERC777-transfer-address-uint256-[``ERC20``'s `transfer`] method, or the new xref:api:token/ERC777.adoc#ERC777-send-address-uint256-bytes-[``ERC777``'s `send`], which fulfills a very similar role, but adds an optional `data` field:
|
||||
|
||||
[source,javascript]
|
||||
----
|
||||
> GLDToken.transfer(otherAddress, 300)
|
||||
> GLDToken.send(otherAddress, 300, "")
|
||||
> GLDToken.balanceOf(otherAddress)
|
||||
600
|
||||
> GLDToken.balanceOf(deployerAddress)
|
||||
400
|
||||
----
|
||||
|
||||
== Sending Tokens to Contracts
|
||||
|
||||
A key difference when using xref:api:token/ERC777.adoc#ERC777-send-address-uint256-bytes-[`send`] is that token transfers to other contracts may revert with the following message:
|
||||
|
||||
[source,text]
|
||||
----
|
||||
ERC777: token recipient contract has no implementer for ERC777TokensRecipient
|
||||
----
|
||||
|
||||
This is a good thing! It means that the recipient contract has not registered itself as aware of the ERC777 protocol, so transfers to it are disabled to *prevent tokens from being locked forever*. As an example, https://etherscan.io/token/0xa74476443119A942dE498590Fe1f2454d7D4aC0d?a=0xa74476443119A942dE498590Fe1f2454d7D4aC0d[the Golem contract currently holds over 350k `GNT` tokens], worth multiple tens of thousands of dollars, and lacks methods to get them out of there. This has happened to virtually every ERC20-backed project, usually due to user error.
|
||||
|
||||
_An upcoming guide will cover how a contract can register itself as a recipient, send and receive hooks, and other advanced features of ERC777!_
|
||||
@ -28,5 +28,4 @@ You've probably heard of the ERC20 or ERC721 token standards, and that's why you
|
||||
|
||||
* xref:erc20.adoc[ERC20]: the most widespread token standard for fungible assets, albeit somewhat limited by its simplicity.
|
||||
* xref:erc721.adoc[ERC721]: the de-facto solution for non-fungible tokens, often used for collectibles and games.
|
||||
* xref:erc777.adoc[ERC777]: a richer standard for fungible tokens, enabling new use cases and building on past learnings. Backwards compatible with ERC20.
|
||||
* xref:erc1155.adoc[ERC1155]: a novel standard for multi-tokens, allowing for a single contract to represent multiple fungible and non-fungible tokens, along with batched operations for increased gas efficiency.
|
||||
|
||||
@ -87,9 +87,7 @@ Easy!
|
||||
|
||||
Want to split some payments between multiple people? Maybe you have an app that sends 30% of art purchases to the original creator and 70% of the profits to the current owner; you can build that with xref:api:finance.adoc#PaymentSplitter[`PaymentSplitter`]!
|
||||
|
||||
In Solidity, there are some security concerns with blindly sending money to accounts, since it allows them to execute arbitrary code. You can read up on these security concerns in the https://consensys.github.io/smart-contract-best-practices/[Ethereum Smart Contract Best Practices] website. One of the ways to fix reentrancy and stalling problems is, instead of immediately sending Ether to accounts that need it, you can use xref:api:security.adoc#PullPayment[`PullPayment`], which offers an xref:api:security.adoc#PullPayment-_asyncTransfer-address-uint256-[`_asyncTransfer`] function for sending money to something and requesting that they xref:api:security.adoc#PullPayment-withdrawPayments-address-payable-[`withdrawPayments()`] it later.
|
||||
|
||||
If you want to Escrow some funds, check out xref:api:utils.adoc#Escrow[`Escrow`] and xref:api:utils.adoc#ConditionalEscrow[`ConditionalEscrow`] for governing the release of some escrowed Ether.
|
||||
In Solidity, there are some security concerns with blindly sending money to accounts, since it allows them to execute arbitrary code. You can read up on these security concerns in the https://consensys.github.io/smart-contract-best-practices/[Ethereum Smart Contract Best Practices] website.
|
||||
|
||||
[[collections]]
|
||||
== Collections
|
||||
@ -103,7 +101,7 @@ Want to keep track of some numbers that increment by 1 every time you want anoth
|
||||
|
||||
=== Base64
|
||||
|
||||
xref:api:utils.adoc#Base64[`Base64`] util allows you to transform `bytes32` data into its Base64 `string` representation.
|
||||
xref:api:utils.adoc#Base64[`Base64`] util allows you to transform `bytes32` data into its Base64 `string` representation.
|
||||
|
||||
This is especially useful for building URL-safe tokenURIs for both xref:api:token/ERC721.adoc#IERC721Metadata-tokenURI-uint256-[`ERC721`] or xref:api:token/ERC1155.adoc#IERC1155MetadataURI-uri-uint256-[`ERC1155`]. This library provides a clever way to serve URL-safe https://developer.mozilla.org/docs/Web/HTTP/Basics_of_HTTP/Data_URIs/[Data URI] compliant strings to serve on-chain data structures.
|
||||
|
||||
@ -122,7 +120,7 @@ contract My721Token is ERC721 {
|
||||
using Strings for uint256;
|
||||
|
||||
constructor() ERC721("My721Token", "MTK") {}
|
||||
|
||||
|
||||
...
|
||||
|
||||
function tokenURI(uint256 tokenId)
|
||||
@ -140,7 +138,7 @@ contract My721Token is ERC721 {
|
||||
|
||||
return string(
|
||||
abi.encodePacked(
|
||||
"data:application/json;base64,",
|
||||
"data:application/json;base64,",
|
||||
Base64.encode(dataURI)
|
||||
)
|
||||
);
|
||||
|
||||
Reference in New Issue
Block a user