If you don't have Rust:
Install Rust https://rustup.rs/
Add wasm32 target to Rust
rustup target add wasm32-unknown-unknownCheck for Rust version 1.51.0.
To compile the simulation tests mg-sim, make sure to have at least Rust 1.51.0.
The mg-sim tests depend indirectly on the arrayvec library.
This library in v0.7.0
uses a Rust feature available from 1.51.0,
const generics.
You can check Rust version with rustc --version.
If an update is needed, run
rustup update stablenear-ts is a utility to generate TypeScript bindings from a Rust contract.
On the other hand, near-md is a utility to generate Markdown documentation from a Rust contract.
You can install it with
cargo install near-synOr alternatively you can install it directly from GitHub
cargo install --git https://github.com/epam/near-syn --branch mainThe package.json contains scripts to facilitate running compilation targets and tests.
The following are the most relevant scripts.
build:contracts. Builds bothmg_nft.wasmandmg_market.wasmcontracts for thewasm32-unknown-unknowntarget. The wasm binaries can be found underrelease/wasm32-unknown-unknown/releasefolder.unit-test:contracts. Runs bothmg-nftandmg-marketcontract unit tests. These tests are being executed locally using the host architecture. In other words, they are not compile down to WebAssembly.app-test:contracts. Executes the application tests. The application tests run both contracts intestnet. It creates user and contract accounts to test the contracts. The accounts IDs used are cached in theneardevfolder. Moreover, the script automatically deploys contracts to thetestnetcontract accounts. It ensures that both contracts are already built before running the tests.app-test:contracts:clean. Removes theneardevfolder which contains the account IDs created forapp-test:contracts.ts:contracts. Generates bothmg-nftandmg-marketcontracts TypeScript bindings insrcfolder. Thenear-tsutility (fromnear-synpackage) needs to be installed to execute this script.md:contracts. Generates bothmg-nftandmg-marketcontracts documentationREADME.mdin their respective folders. Thenear-mdutility (fromnear-synpackage) needs to be installed to execute this script.dev-deploy:contract. WIP. Deploys contracts to a dev account.deploy:contract. WIP. Deploys contracts to an already logged in account.build:lib. Builds the contract client library.lint:lib. Provides linting checks for the contract client library.measure:storage-costs. Performs an arbitrary number of operations forcollectiblesandtokensonnft-contractandmarket-contract. Collects the information on how much Ⓝ reserved for storage. Generatesdata.jsfile intestsfolder.
- User: any Internet user who may (or may not) have NEAR Account
- NEAR User: a User who has NEAR Account
- Creator (aka Artist): a User who has NEAR Account and MintGate account. Creator creates Collectibles. Creator cannot be changed once set for Collectible.
- Admin: a NEAR User that operates MintGate NFT contract, or another NEAR Account that takes this role as assigned during build and deployment process of NFT contract.
- Claimer (aka Holder): a NEAR User who mints Tokens for selected Collectible on the NFT contract. Creator and Admin also can act as a Claimer. Claimer becomes an Owner after s_he successfully minted a Token.
- Buyer: a NEAR User who purchases Token from Marketplace. Buyer becomes an Owner after s_he successfully purchased a Token.
- Seller: an Owner who sells Token on the Marketplace from the moment when he approves Marketplace until deal will be settled, and he looses ownership over a Token.
- Owner: a NEAR User who owns a Token of any Collectible as a result of minting it on NFT contract, buying from Marketplace, or receiving it as a gift from another Owner.
- Royalty beneficiary: a NEAR User who receives % from each deal closed on any of the Marketplaces with each Token. There will be exactly 1 Royalty beneficiary. It may be a Creator, but may be not. Royalty beneficiary cannot be changed once set for Collectible.
- Collectible: NFT with information about its Creator, Supply and other Metadata, identified uniquely by GateID provided externally from MintGate platform.
- GateID: unique identifier of Collectible that originally generated by MintGate and stored in their master database off-chain.
- Supply: maximum amount of Tokens that can be minted for given Collectible. Minimum supply is 1 ("Pure NFT"). When NFT has Supply > 1, it can be named a semi-fungible Token.
- Current Supply: number of remaining Tokens available for minting for given Collectible. Current Supply <= Supply, and always decreasing towards 0. When CurrentSupply=0 then Tokens for this Collectible can be obtained from Marketplace, or as a result of direct transfer from Owner to NEAR User (as a gift or a deal settled off-chain).
- Token: an asset on NFT Contract that is identified by unique ID and that always belongs to one Collectible and has one Owner.
measure:storage-costs script measures the costs of storage for nft-contract and market-contract. It performs operations on collectibles and tokens on the contracts, collects the information on changes in Ⓝ reserved for storage for different methods.
By default, measure:storage-costs adds 20 collectibes and 40 tokens for test account (it reuses already present accounts or creates new ones and deploys contracts if needed).
It is also possible to instruct the script to add the arbitrary number of collectibles and tokens.
To do so run from project's root:
ts-node test/measure.ts --collectibles 100 -- tokens 200
where:
--collectibles: number of collectibles to add. Number of timescreate_collectible,delete_collectiblewill be executed.--tokens: number of tokens to add.claim_token,nft_transfer,nft_approve,batch_approve,nft_revoke,buy_tokenwill be executed for this number of tokens.
The script generates data.js file in tests folder. The information from data.js as datasets for charts in chart.html file also located in tests folder. To see the charts open chart.html in any browser.
Example of storage costs charts with data generated by running measure script with default values:
