├── BeGood.md ├── FAQ.md ├── README.md ├── legal └── wallet_disclaimer.md ├── owners_manual ├── img │ ├── Autonoms-Converter-Contract-1.jpg │ ├── Autonoms-Converter-Contract-2.jpg │ ├── Autonoms-Converter-Contract-3.jpg │ ├── Autonoms-Converter-Contract-4.jpg │ ├── Autonoms-Converter-Contract-5.jpg │ ├── figure-1.jpg │ ├── figure-2.jpg │ ├── figure-3.jpg │ ├── figure-4.jpg │ ├── figure-5.jpg │ ├── figure-6.jpg │ ├── figure-7.jpg │ └── logo.png ├── owners_manual.md ├── owners_manual_jp.md ├── owners_manual_ko.md ├── owners_manual_ru.md └── owners_manual_zh_CN.md └── validatordocument ├── img ├── Figure-1.png ├── Figure-2.png ├── Figure-3.png ├── Figure-4.png └── Figure-5.png └── validatordocument.md /BeGood.md: -------------------------------------------------------------------------------- 1 | # Be Good to Each Other 2 | * Be friendly and patient 3 | * Be welcoming - we want to embrace newcomers, encourage contribution 4 | * Be professional 5 | * [Assume good faith](https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith) 6 | * Treat others as you would like to be treated 7 | 8 | Further reading: [Open Source Contributor Covenant](http://contributor-covenant.org/version/1/4/) 9 | -------------------------------------------------------------------------------- /FAQ.md: -------------------------------------------------------------------------------- 1 | # Metronome FAQ 2 | 3 | 1. [About Metronome](#about-metronome) 4 | 1. [What is Metronome?](#what-is-metronome) 5 | 1. [What can Metronome do that other cryptocurrencies cannot do?](#what-can-metronome-do-that-other-cryptocurrencies-cannot-do) 6 | 1. [What can Metronome be used for?](#what-can-metronome-be-used-for) 7 | 1. [Where can I read the full Metronome Owner's Manual?](#where-can-i-read-the-full-metronome-owners-manual) 8 | 1. [How was Metronome launched?](#how-was-metronome-launched?) 9 | 10 | 1. [Initial and Daily Supply Auctions](#initial-and-daily-supply-auctions) 11 | 1. [How will the Metronome token sale take place?](#how-will-the-metronome-token-sale-take-place) 12 | 1. [When did the Metronome initial supply auction start?](#when-did-the-metronome-initial-supply-auction-start) 13 | 1. [Was there a pre-sale?](#was-there-a-pre-sale) 14 | 1. [Is there a whitelist for auction participation?](#is-there-a-whitelist-for-auction-participation) 15 | 1. [What was the last price in the Initial Supply Auction?](#what-was-the-last-price-in-the-initial-supply-auction) 16 | 1. [How do I participate in Metronome's Initial Auction and Daily Supply Lots?](#how-do-i-participate-in-metronomes-initial-supply-auction-and-daily-supply-lots) 17 | 1. [How does new Metronome enter the ecosystem?](#how-does-new-metronome-enter-the-ecosystem) 18 | 1. [How soon did the daily auctions begin once the initial supply auction finished?](#how-soon-did-the-daily-auctions-begin-once-the-initial-supply-auction-finished) 19 | 1. [Who gets the proceeds of the MET auctions?](#who-gets-the-proceeds-of-the-met-auctions) 20 | 1. [What prevents a large hash-power miner (or pool of miners) from dominating purchases?](#what-prevents-a-large-hash-power-miner-or-pool-of-miners-from-dominating-purchases) 21 | 22 | 1. [How Metronome Works](#how-metronome-works) 23 | 1. [What components comprise Metronome?](#what-components-make-up-metronome) 24 | 1. [What blockchains are MET compatible with?](#what-blockchains-are-met-compatible-with) 25 | 1. [When will the first target chain (ETC) have Metronome contracts deployed?](#when-will-the-first-target-chain-etc-have-metronome-contracts-deployed) 26 | 1. [Has the smart contract that collects ETH been professionally audited for security issues](#has-the-smart-contract-that-collects-eth-been-professionally-audited-for-security-issues) 27 | 1. [What risks are involved with MET?](#what-risks-are-involved-with-met) 28 | 29 | 1. [Metronome and Its Authors](#metronome-and-its-authors) 30 | 1. [Why did Metronome Authors create Metronome?](#why-did-metronome-authors-create-metronome) 31 | 1. [Why is the token called "Metronome"?](#why-is-the-token-called-metronome) 32 | 1. [Will there be a lock-up in tokens retained by Metronome Authors?](#will-there-be-a-lock-up-in-tokens-retained-by-metronome-authors) 33 | 1. [Will Metronome authors govern MET?](#will-metronome-authors-govern-met) 34 | 1. [Metronome Wallet FAQ](#metronome-wallet-faq) 35 | 1. [Can I download the MET wallet on mobile?](#can-i-download-the-met-wallet-on-mobile) 36 | 1. [What does this returned error mean, “Insufficient funds for gas * price + value?”](#what-does-this-returned-error-mean-insufficient-funds-for-gas-*-price-+-value) 37 | 1. [Why haven’t the Metronome Wallet balances updated after a transaction?](#why-havent-the-metronome-wallet-balances-updated-after-a-transaction) 38 | 39 | ## About Metronome 40 | 41 | ### What is Metronome? 42 | 43 | Metronome (“Metronome” or “MET”) is a new cryptocurrency designed to bring institutional-class endurance to the cryptocurrency category through: 44 | 45 | * **Self-governance** - Metronome is designed to function indefinitely without management by a particular group or individual, even its authors. 46 | * **Reliability** - The system is architected for steady and predictable token supply via descending price auctions. 47 | * **Portability** - With the ability to move between blockchains, the cryptocurrency is further protected from management issues and instability. 48 | 49 | ### What can Metronome do that other cryptocurrencies cannot do? 50 | 51 | We expect that MET will act as a store of value that is decentralized across blockchains. Since MET will be capable of being exported and imported across chains, it will empower users to move MET for whatever reason they desire. Other cryptocurrencies cannot do this. 52 | 53 | Cross-chain export and import of MET will provide the ability to migrate from one blockchain to another in the event of a failure. 54 | 55 | MET also allows for subscriptions, or recurring payments on the blockchain that are automatic. This is something cryptocurrencies have struggled with, until now—MET users can schedule repeat payments easily. 56 | 57 | Additionally, MET uses custom funcationality for enhanced security and transfer. 58 | 59 | ### What can Metronome be used for? 60 | 61 | While many different communities and institutions will discover their own use for Metronome, it was designed for any scenario where reliability is a first-order variable for selecting a cryptocurrency. 62 | 63 | Some possible use cases include, but are not limited to: 64 | 65 | * Decentralized store of value across blockchains 66 | * Advanced payment settlement: 67 | * Mass Pay — allowing users to send tokens to multiple addresses with one action. While mass pay is a well-known and used feature on the Bitcoin network, it is lacking on the Ethereum network. 68 | * Subscriptions — allowing users to set up recurring payments between themselves and other parties. Subscription is a payment feature unique to Metronome. Users can set up recurring payments between themselves and other parties by authorizing that party to take a certain amount of MET from a wallet on a recurring, periodic basis. 69 | 70 | A unique Metronome payments feature is subscription. Users can set up recurring payments between themselves and other parties by authorizing that party to take a certain amount from a wallet on a weekly basis. 71 | 72 | 73 | ### Where can I read the full Metronome Owner's Manual? 74 | 75 | The owner's manual is available [here](https://github.com/autonomoussoftware/documentation/blob/master/owners_manual/owners_manual.md). 76 | 77 | 78 | ### How was Metronome launched? 79 | 80 | There are phases, both of which employ the descending price auction ("DPA”) pricing mechanism: 81 | 82 | * **The Initial Supply Auction**, serving as the official launch of Metronome, where 10,000,000 MET tokens will be issued and made available 83 | * **The Daily Supply Auction**, The Daily Supply Auction, where new tokens are added to the auction ad infinitum, at the rate that is the greater of (i) 2,880 MET per day, or (ii) an annual rate equal to 2.0000% of the then-outstanding supply per year. 84 | 85 | 86 | ## Initial and Daily Supply Auctions 87 | 88 | ### How will the Metronome token sale take place? 89 | 90 | The Initial Supply Auction serves as the official launch of Metronome. 8,000,000 MET tokens (10 million, less the 20% one-time author retention) will be made available to the public with a descending price auction. The price per MET will begin at a maximum price of 2 ETH per MET and floor price of 0.0000033 ETH. As time progresses and MET remains available, the auction price will decline linearly until the auction ends or all MET are sold. Metronome employs DPAs to establish predictable and transparent pricing for the MET being issued by the contract. 91 | 92 | ### When did the Metronome initial supply auction start? 93 | 94 | June 18, 2018, at Midnight UTC. 95 | 96 | ### Was there a pre-sale? 97 | 98 | **No**, the first time that anyone was able to purchase Metronome was during the Initial Supply Auction. 99 | 100 | ### Is there a whitelist for auction participation? 101 | 102 | **No**, there is no whitelist. 103 | 104 | ### What was the last price in the Initial Supply Auction? 105 | The last MET in the Initial Supply Auction was sold for 0.0027815 ETH 106 | 107 | ### How do I participate in Metronome's Initial Supply Auction and Daily Supply Lots? 108 | 109 | To participate in Metronome’s Initial Supply Auction (and, every day thereafter, the Daily Supply Lots) you will need access to an ERC20-compatible Ethereum wallet where you hold the private keys and sufficient ETH to purchase MET. Do not use wallets provided by exchanges. Be sure to use enough gas when sending your ETH. If you do not use enough gas, your transaction will be rejected and you will have to send your ETH again. 110 | 111 | Ethereum can be purchased from cryptocurrency exchanges. Again, make sure that once you purchase your ETH, you transfer it into an ERC20-compatible Ethereum wallet where you hold the private keys. 112 | 113 | Once you have sufficient ETH in an ERC20-compatible Ethereum wallet, you may participate in the auction by sending the desired amount to: 114 | 115 | 116 | **0x9d9BcDd249E439AAaB545F59a33812E39A8e3072** 117 | 118 | 119 | You should receive your MET almost immediately following receipt of your ETH by the Metronome smart contracts, at the price of purchase. Metronome purchased during the Initial Supply Auction will become transferrable following the close of the Initial Supply Auction. Metronome purchased during the Daily Supply Lots will be transferable immediately following receipt. 120 | 121 | 122 | ### How does new Metronome enter the ecosystem? 123 | 124 | Following the initial auction, MET is added to MET’s Daily Supply Lots (“DSL”) every 24 hours, at the rate that is the greater of (i) 2,880 MET per day, or (ii) an annual rate equal to 2.0000% of the then-outstanding supply per year. Newly-minted MET from the DSL enters the ecosystem via a DPA. All tokens in the DSL start at a maximum price set by the contract at the previous auction’s last price (the price of the last Metronome sold if the auction sells out, or the final price in a given auction should an auction lot still have supply) multiplied by two. In the event a DSL does not sell a single Metronome, the starting price of the following auction will be 1/100th of the last price a Metronome was purchased at a DSL auction. Every 60 seconds, the price of MET remaining in the DSL is reduced to 99% of its previous price. After some time, we expect the price of remaining tokens will become low enough for the DSL to sell out. The absolute floor price on any Daily Supply Lots auction is 1 Wei, to prevent the price from hitting zero-- which would make setting the following auction’s initial price impossible. 125 | 126 | In the event that there are unsold MET at the end of the daily auction, those tokens will be held over and added to the next DSL. For example, if 1,000 MET went unsold, the next DSL would introduce the scheduled 2,880 MET plus the remaining 1,000 MET from the previous day. 127 | 128 | We expect that the mintage rate for approximately the first 40 years will be 2,880 MET per day. After approximately 40 years, the mintage rate will increase as shown below. 129 | 130 | | Time | Circulating MET (End of Year) | Mintage rate (End of Year) | Daily supply lot | 131 | | ------------ | -----------: | ------: | ------: | 132 | | T + 1 Year | 11,051,200 | 10.512% | 2,880 | 133 | | T + 5 Years | 15,258,880 | 7.399% | 2,880 | 134 | | T + 10 Years | 20,517,760 | 5.400% | 2,880 | 135 | | T + 40 Years | 52,076,800 | 2.066% | 2,880 | 136 | | T + 70 Years | 94,382,561 | 2.000% | 5,070 | 137 | 138 | 139 | ### How soon did the daily auctions begin once the initial supply auction finished? 140 | 141 | The first DSL took place the following midnight UTC after the close of the Initial Supply Auction. 142 | 143 | ### What happens to the proceeds from Metronome Auctions? 144 | 145 | 100% of the proceeds of the Initial Supply Auction and 100% of the future Daily Supply Lots’ proceeds go to Metronome’s Autonomous Proceeds Provider (“APP”) contracts – the Proceeds and Autonomous Converter Contracts – to provide long term support for the community and help incubate Metronome in its first years. Metronome authors receive none of the proceeds from any auction. 146 | 147 | Please see [either of these](https://medium.com/@MetronomeToken/on-metronome-author-retention-and-contract-behavior-73dad8f16494) [helpful articles](https://medium.com/@MetronomeToken/proceeds-for-the-community-not-the-authors-d41874d4d41f) for more information. 148 | 149 | ### What prevents a large hash-power miner (or pool of miners) from dominating purchases? 150 | 151 | Anyone can potentially soak up new supply, simply buying early and therefore paying more. That is how descending price auctions make the process predictable and the reason why we are using them. 152 | 153 | Miners can potentially front-run a non-miner transaction—but they must also (a) pay more, otherwise their actions have no impact on the auction, and (b) win a block, which is unlikely unless they are extremely large pools. 154 | 155 | ## How Metronome Works 156 | 157 | ### What components comprise Metronome? 158 | 159 | Metronome is comprised of four fully-autonomous and cooperative smart contracts. 160 | 161 | * Metronome Ledger ERC20 162 | * This is the token’s smart contract ledger and dictates how the token behaves 163 | * Custom functionality for enhanced decentralized transfer and security 164 | * Auctions Contract 165 | * This smart contract interacts with the ledger contract above and operates the descending price auctions 166 | * Sets the rules for the initial supply auction and the daily supply lot 167 | * Sends ETH from the Auctions Contract to the Proceeds Contract 168 | * Autonomous Proceeds Provider (two contracts) 169 | * Automatically provides supply between MET and ETH 170 | * Comprised of two smart contracts 171 | * Proceeds Contract 172 | * Supports supply by holding 100% of the DSL and transferring 0.25% of the total accumulated balance to Autonomous Converter Contract every day 173 | * Autonomous Converter Contract 174 | * Allows users to sell their MET for ETH or ETH for MET 175 | * Price determined by contents of contract at time of sale 176 | 177 | 178 | ### What blockchains are MET compatible with? 179 | 180 | Metronome will be initially issued on Ethereum with Ethereum Classic, Rootstock, and Qtum support expected to follow. As the community continues developing MET, it may be compatible with even more blockchains. 181 | 182 | ### When will the first target chain (ETC) have Metronome contracts deployed? 183 | 184 | Q1, 2019 - You can read more in [this recent update](https://medium.com/@MetronomeToken/metronome-meetup-wrap-up-chicago-august-2018-a34e5350a977). 185 | 186 | ### Has the smart contract that collects ETH been professionally audited for security issues? 187 | 188 | The smart contract has been audited by three independent consultants: Zeppelin Solutions, Coinspect, and Gustav Simonsson. 189 | 190 | 191 | ### What risks are involved with MET? 192 | 193 | Though the Metronome code has been thoroughly audited by multiple independent parties, there are always some potential risks, as with any cryptocurrency. These potential risks include, among other risks: 194 | 195 | * Chain dependence (e.g., chain mutability or chain denial of service): as the first cross-chain cryptocurrency, Metronome was built to help mitigate this issue. 196 | * Immutable bugs: Though the code has been thoroughly audited by independent parties, there is always this possibility that a bug may be immutable or need to be worked around. 197 | * Contract attacks: Two categories of contract attacks are: (1) technical, which exploit some attribute of the contract's bytecode-defined EVM behavior and (2) economic, where attacks induce unintended behavior from the contract functioning as designed. 198 | 199 | 200 | ## Metronome and its Authors 201 | 202 | ### Why did Metronome Authors create Metronome? 203 | 204 | We looked at the current landscape of distributed blockchain-based financial products and saw a novel opportunity to launch a cryptocurrency with equal public access and the need for a cross-chain solution. Metronome is a self-governed cryptocurrency that we believe is reliable, equally accessible to the public, and immune to community discord or individual drama. 205 | 206 | ### Why is the token called “Metronome”? 207 | 208 | We believe the cryptocurrency is stable, predictable, and constant. Our innovation needed a name that carried the same weight as its performance. The enduring beat of tokens being added to the ecosystem per day is unending and reliable, like a musical metronome keeping time. 209 | 210 | ### Will there be a lock-up in tokens retained by Metronome Authors? 211 | 212 | Metronome’s authors will receive 20% of the initial MET supply as a one-time author’s retention. 25% of this will be available upon the closing of the initial supply auction. The remaining 75% is released quarterly over 12 quarters. 213 | 214 | 100% of ETH proceeds from the auction will remain in the Metronome ecosystem. Metronome authors can buy and sell their own MET at their discretion. Following the launch of the initial auction, the Metronome ecosystem is entirely in the hands of the smart contracts and the community. 215 | 216 | ### Will Metronome authors govern MET? 217 | 218 | No. Metronome will be governed by its smart contracts and users. Metronome authors plan on remaining active within the community of users and developers by continuing to grow the ecosystem with MET-enabled and compatible products. However, after its launch, authors will have no more control over MET than any other member of the MET community. 219 | 220 | ## Metronome Wallet FAQ 221 | 222 | ### Can I download the MET wallet on mobile? 223 | 224 | Yes, you can find download links for the iOS and Android versions of the wallet at https://metronome.io/apps/ 225 | 226 | ### What does this returned error mean, “Insufficient funds for gas * price + value?” 227 | 228 | This error usually happens when a user tries to send more funds than are in the wallet - likely because the balance-to-be-sent did not include enough room for transaction fees. The recommended solution is to try the transaction again by sending a lower balance to provide enough room for transaction fees. 229 | 230 | The amount of gas required to successfully transact on the Ethereum network (with either MET or ETH) can vary based on the network’s load relative to its capacity. Tools like https://ethgasstation.info/ can be helpful in determining the amount of gas necessary. 231 | 232 | ### Why haven’t the Metronome Wallet balances updated after a transaction? 233 | 234 | We recommend you refresh/rescan the wallet, and your cryptocurrency balances should be updated. This can be done by entering the wallet, clicking “tools” in the lower left corner and using the “rescan transactions” tool. And as always, have the wallet seed phrase safe and on-hand when rescanning. 235 | 236 | Note that it is possible the transaction failed, so please search the transaction hash on Etherscan. In event of a transaction failure/return of ETH or MET, this means the user has only lost gas. 237 | 238 | ## Chainhop FAQs 239 | 240 | ### What is a chainhop and how is it different than other interoperability solutions? 241 | A Metronome chainhop is a movement of the same 1 MET from one network to another network. Metronome only manages a single currency, sending the same token across multiple chains – and back. Others are a token swap network managing many coins, never sending the same tokens back and forth. 242 | 243 | See [the team’s article](https://medium.com/@MetronomeToken/how-a-chainhop-is-different-than-other-interoperability-solutions-6446cdf6e2c) for more information on how Metronome is different than other interoperability solutions. 244 | 245 | ### What is a Validator? What do they do? 246 | A Validator is off-chain software running on distributed nodes, maintained by a publicly known entity, which exists in order to propagate an event from one blockchain to another. Validators are responsible for observing a blockchain for events, validating cross chain movements (as described below), and voting on the validity of that event. Initially, there are 5 validators but eventually we will allow any trusted entity to run a validator in order to encourage a more decentralized MET token movement process – more may be added in the future. The need for validators fades in subsequent phases. 247 | 248 | ### Who are the validators? 249 | The initial phase 1 Metronome validators are: 250 | - ETC Labs 251 | - The QTUM Team 252 | - Bloq, Inc. 253 | - Veriblock 254 | - Spacechain 255 | 256 | ### What are the validator phases? 257 | In order to ensure security and usability of Metronome’s cross-chain features, there will be three phases of cross chain rollout. Each subsequent phase will further decentralize the process for completing cross-chain moves. 258 | 259 | **Phase 1 - Federated Network of Validators** 260 | 261 | In phase 1 a federated network of validators operates in a multi-signature, multi-party approach to validate that import/export movements follow the Metronome protocol. MET owners may export at any time. 262 | 263 | In the event of a chain fork, the quorum of validators will choose which side of a fork supports Metronome. 264 | 265 | **Phase 2 - Chain Attestors and stake weighting** 266 | 267 | Phase 2 seeks to decentralize and rely less on validators. For each blockchain, Metronome will look to chain oracles that provide a very specific piece of data: What is the correct chain for a particular currency? 268 | 269 | The goal is to automate the choosing of hard fork sides, automatically ingesting and following the community choice for each blockchain. 270 | 271 | Finally, as a global check on contentious events via minority chains and attack-style hard forks, the percentage of total Metronome tokens on a particular chain shall have that level of percentage global weight, in the event of a discrepancy in the Metronome consensus protocol between two versions of the MET global supply timeline. 272 | 273 | **Phase 3 - Fully autonomous, stake-weighted cross chain transfers** 274 | 275 | Phase 3 of cross-chain validation provides a fully decentralized end state. The model mirrors that of the original Bitcoin blockchain, a full consensus protocol. This model includes 276 | 277 | - **A node.** In MET Phase 3, each lily pad may be considered like a single Bitcoin node. 278 | - **A blockchain.** In MET Phase 3, each lily pad maintains its own independent copy of the history of all MET cross-chain transfers. 279 | - **A movement.** In MET Phase 3, each user-generated import may be considered like a single unconfirmed Bitcoin movement. An import is considered confirmed after 24 blocks (24 hours). 280 | - **A block.** In MET phase 3, a block may be generated once per hour, on a stake-weighted basis (total stake weight of entire lily pad). This block is shared by users desiring imports to each lily pad. 281 | - **Consensus protocol** is Bitcoin design, with proof-of-stake modification. We call this APS, Autonomous Proof of Stake, because it is different from both POS and DPOS. In MET phase 3, each lily pad is a stake-weighted autonomous actor. 282 | 283 | This is possibly the first cross-blockchain blockchain. Each lily pad -- each set of smart contracts -- uses a Bitcoin-style consensus protocol, with Proof-of-Stake modification to determine the outcome of hard forks. This consensus protocol automatically chooses one side of a hard fork over another. 284 | 285 | See the [Validator Document](https://github.com/autonomoussoftware/documentation/blob/master/validatordocument/validatordocument.md) for more information on the Validator phases. 286 | 287 | ### What do I need to do in order to complete a chainhop? 288 | MET owners who wish to move their MET across chains will need: 289 | - MET 290 | - The native token of the export chain (think ETH, ETC, so forth) in order to pay gas 291 | - The native token of the import chain (think ETH, ETC, so forth) in order to pay gas 292 | - Small amount of MET as a fee (0.5% of total transferred) to go to validators. 293 | - The Metronome wallet or knowledge of how to use a wallet via CLI for necessary `TokenPorter` [API calls](https://github.com/autonomoussoftware/documentation/blob/master/owners_manual/owners_manual.md#tokenporter-api). 294 | 295 | ### Why is the confirmation time so long, and will it ever get shorter? 296 | The 24 hour confirmation is to defend against chain reorganization and 51% attacks. The team is designing a solution to auto adjust based on current hashing power of the network – the lower the hashing power, the higher confirmation requirement. Because a chainhop involves multiple networks, one must consider hashpower of both networks to avoid double spending during a chainhop. Our security auditors suggested this mechanism (especially in light of recent reorganization attacks). For phase 3, there will be certain block confirmation for validations but it may be less than this. 297 | 298 | ### I had to retry my transaction, why? 299 | If a chainhop does not confirm in the first 24 hours, a “retry” in the wallet may be required. Sometimes network activity can jar a node out of sync, extending the expected confirmation time of chainhops. This is not expected to be a regular issue, especially as the validator network matures. 300 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Metronome Cryptocurrency Documentation 2 | 3 | ## Index 4 | 5 | 1. [FAQ](FAQ.md) 6 | 1. [Be Good](BeGood.md) 7 | 1. [Owner's Manual](owners_manual/owners_manual.md) 8 | -------------------------------------------------------------------------------- /legal/wallet_disclaimer.md: -------------------------------------------------------------------------------- 1 | Copyright 2018 Autonomous Software 2 | 3 | Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: 4 | 5 | The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. 6 | 7 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 8 | 9 | ADDITIONAL TERMS REGARDING SOFTWARE USE 10 | 11 | The Software represents cryptocurrency wallet software (the “Wallet”). IF YOU LOSE ACCESS TO YOUR WALLET OR YOUR ENCRYPTED PRIVATE KEYS AND YOU HAVE NOT SEPARATELY STORED A BACKUP OF YOUR WALLET AND CORRESPONDING PASSWORD, ANY AMOUNTS YOU HAVE STORED WITHIN WALLET WILL BECOME INACCESSIBLE. Autonomous Software cannot retrieve your private keys or passwords if you lose or forget them. Autonomous Software does not control any of the protocols that govern any cryptocurrency and cannot confirm any transaction 12 | 13 | Transactions with cryptocurrencies carry inherent risks. Cryptocurrency values may involve risk of capital loss from unfavorable fluctuation in cryptocurrency values, technical defects inherent in cryptocurrencies, exchange-related risks, policy risks, regulatory risks, liquidity, and market price fluctuation and demand. The value of any cryptocurrency is not ensured. The worth of any amount of cryptocurrency and may lose all worth at any moment of time due to the risky nature of cryptocurrencies. Virtual currency is not legal tender, is not backed by the government, and accounts and value balances are not subject to FDIC or SIPC protections, among others. You are solely responsible for any such losses and the management of the cryptocurrencies in your Wallet. There may be an increased risk of loss of cryptocurrency due to cyber-attacks. Autonomous Software shall not be liable for any losses to your Wallet you may suffer as a result of a security breach, fraudulent activity or hacking event. 14 | -------------------------------------------------------------------------------- /owners_manual/img/Autonoms-Converter-Contract-1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/owners_manual/img/Autonoms-Converter-Contract-1.jpg -------------------------------------------------------------------------------- /owners_manual/img/Autonoms-Converter-Contract-2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/owners_manual/img/Autonoms-Converter-Contract-2.jpg -------------------------------------------------------------------------------- /owners_manual/img/Autonoms-Converter-Contract-3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/owners_manual/img/Autonoms-Converter-Contract-3.jpg -------------------------------------------------------------------------------- /owners_manual/img/Autonoms-Converter-Contract-4.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/owners_manual/img/Autonoms-Converter-Contract-4.jpg -------------------------------------------------------------------------------- /owners_manual/img/Autonoms-Converter-Contract-5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/owners_manual/img/Autonoms-Converter-Contract-5.jpg -------------------------------------------------------------------------------- /owners_manual/img/figure-1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/owners_manual/img/figure-1.jpg -------------------------------------------------------------------------------- /owners_manual/img/figure-2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/owners_manual/img/figure-2.jpg -------------------------------------------------------------------------------- /owners_manual/img/figure-3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/owners_manual/img/figure-3.jpg -------------------------------------------------------------------------------- /owners_manual/img/figure-4.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/owners_manual/img/figure-4.jpg -------------------------------------------------------------------------------- /owners_manual/img/figure-5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/owners_manual/img/figure-5.jpg -------------------------------------------------------------------------------- /owners_manual/img/figure-6.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/owners_manual/img/figure-6.jpg -------------------------------------------------------------------------------- /owners_manual/img/figure-7.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/owners_manual/img/figure-7.jpg -------------------------------------------------------------------------------- /owners_manual/img/logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/owners_manual/img/logo.png -------------------------------------------------------------------------------- /owners_manual/owners_manual_jp.md: -------------------------------------------------------------------------------- 1 | ![Metronome](img/logo.png) 2 | 3 | バージョン 0.986（最終更新日 2018年5月30日） 4 | 5 | **注記：** 6 | 7 | \（1）このオーナーズマニュアルの草案は進行中の作業で、新しいタイプの暗号通貨であるMetronomeの設計と構造について説明しています。Metronomeとその根底にあるテクノロジーはまだ開発中であり、このオーナーズマニュアルには開発サイクルを通して変更が反映されるように、このプロセス中終始更新されます。資料データの正確性についてはありとあらゆる注意を払っていますが、オーナーズマニュアルにある資料データの正確性および完璧性はMetronomeの作者とパートナーによって保証されるものではありません。 8 | 9 | \(2) 潜在的なMetronomeの購入者およびMetronomeエコシステムへの参加者は、付録 \[A\]にある了承事項および免責事項を含め、このオーナーズマニュアルを読み、購入する前にいかなるリスクも注意深く検討してください。 10 | 11 | **オーナーズマニュアルのライセンス** 12 | 13 | © 2018 Autonomous Software. ライセンサーによって明示的に承諾されているもの以外は全権保有。 14 | 15 | 16 | AUTONOMOUS SOFTWARE（「ライセンサー」）が本書METRONOMEオーナーズマニュアル（「オーナーズマニュアル」）とその汎用バージョン（以下に定義）の排他的な所有権、および全権、権限および権利、すべての著作権および知的財産権を所有、保持します。オーナーズマニュアルと汎用バージョンはここでは集合的に「作業」として参照されています。 17 | 18 | 「METRONOME」、「MET」、およびMETRONOMEのロゴ（集合的に「METRONOMEマーク」）はライセンサーの商標で、ライセンサーの明示的な書面による許可のもとにのみ使用が許可されています。METRONOMEマークまたは類似したマークをいかなる製品またはサービスと関連して、あるいは広告宣伝、またはソフトウェアやハードウェア上を含め、混同を招くような方法で使用することは禁じられています。 19 | 20 | 1. **ライセンスの許諾と制限。**このライセンスの利用規約は変更されることがあります。 21 | ライセンサーは、オーナーズマニュアル全体（ただし、一部ではなく）を修正せずにコピー、表示、および配布する、 22 | 汎用バージョン（以下に定義）の派生的作業を修正または作成する、 23 | そしてそのような作業をコピー、表示、および配布する、 24 | 世界中のロイヤリティ無しの永続的なライセンスを 25 | ここにおいてあなたに許諾します。 26 | これは、前述のいずれもが、あなた、またはあなたの作業、または暗号通貨、 27 | またはスマートコントラクト、またはここに記述されているテクノロジーが 28 | ライセンサーまたはその関連会社と関連している、またはそれらによって保証されているという含意を持たないことを 29 | 条件としています。上記の権利は、現在周知または今後考案されるかにはかかわらず、 30 | すべてのメディアとフォーマットで行使することが 31 | できます。上記の権利には、他のメディアおよびフォーマットで 32 | 権利を行使するために技術上必要な修正を行う権利が 33 | 含まれています。作業を配布または公的に実行する度に、 34 | このライセンス下で許諾されたライセンスと同じ規約条件で 35 | 「作業」に対するライセンスをライセンサーは 36 | 受領者に与えます。「汎用バージョン」とは、ライセンサー、ライセンサーの関連、 37 | またはMetronome、MET、 38 | またはMetronomeマークを含まない、 39 | オーナーズマニュアルのバージョンを意味します。 40 | 41 | 2. **オーナーズマニュアルへの提案された修正。**オーナーズマニュアルへの修正の提案を提出 42 | することによって、提案した修正に関して 43 | 制限なくすべての著作権をライセンサーに与えること 44 | になります。そのような場合、ライセンサーは独自の判断に基づいて 45 | 提案された変更をオーナーズマニュアル 46 | （全体または一部、変更された、または変更されていない形式） 47 | に含める、または含めないことを選択することができます。 48 | 49 | 3. **表明および保証の免責**オーナーズマニュアルは、いかなる種類の、明示的または暗示的、あるいは法的またはそれ以外の保証なく、そのまま提供されています。これには、制限がなく、タイトル、商品性、特定目的に対する適正、非侵害性、正確性、またはエラーの存在または非存在の保証が含まれます。ある管轄区域においては、暗示的な保証の除外を許可しない場合があり、その場合はそのような除外はその区域に住む者には適用されません。 50 | 51 | 4. **実施可能性**。このライセンスのいかなる条項が無効であるか、または適用される法律下で実施不可能な場合、このライセンスのその他の残りの条件の有効性および実施可能性には影響を与えないものとし、この同意書に対して両者によって何らかの行為がとられることなく、そのような条項は、それを有効で実施可能なものにするために必要最低限な改正が行われるものとします。放棄または同意が書面によるもので、非難された側によって署名されていないかぎり、このライセンスのいずれの条件または条項も放棄されたものとはみなされず、いかなる侵害にも同意していないものとします。 52 | 53 | 5. **条約の権利**。本ライセンスで許諾される権利および主題事項は、文学および芸術作品の保護に関するベルン条約（1979年9月28日改正）、1961年ローマ条約、1996年のWIPO著作権条約、1996年のWIPO実演及びレコードに関する世界知的所有権機関条約、および万国著作権条約（1971年7月24日改訂）に基づいています。これらの権利および内容は、適用される国家法律においてこれらの条約の条項の実施に対応する条項に従って、ライセンス条件を施行する関連管轄区域で効力を発するものとします。該当する著作権法の下で与えられている標準の権利にこのライセンスでは与えられていないその他の権利が含まれている場合、そのような追加の権利はこのライセンスに含まれているものとみなされます。このライセンスは、適用される法律下でいかなる権利のライセンスを制限することを意図していません。 54 | 55 | 目次 56 | ================= 57 | 58 | **[目次](#モクジ)** 59 | 60 | **[表と図の一覧](#ヒョウトズノイチラン)** 61 | 62 | **[モチベーション](#モチベーション)** 63 | 64 | > [暗号通貨を文字通り次のレベルへ持っていく](#taking-cryptocurrency-to-the-next-level-literally) 65 | 66 | **[エグゼクティブサマリー](#エグゼクティブサマリー)** 67 | 68 | **[背景](#ハイケイ)** 69 | 70 | > [ブロックチェーンテクノロジー](#blockchain-technology) 71 | > 72 | > [暗号通貨](#cryptocurrency) 73 | > 74 | > [競り下げ式オークション](#descending-price-auctions) 75 | 76 | **[Metronomeの紹介](#metronomeノショウカイ)** 77 | 78 | **[Metronomeの仕組み](#metronomeノシクミ)** 79 | 80 | > [クロスブロックチェーンのポータビリティ](#cross-blockchain-portability) 81 | > 82 | > [分散型、自発的合意ガバナンス](#distributed-voluntary-consensus-governance) 83 | 84 | **[今日の暗号通貨の市場環境](#cryptocurrency-market-context-to-date) ** 85 | 86 | > [活動状況](#the-landscape) 87 | 88 | **[Metronomeのコントラクトと技術面](#metronomeノコントラクトトギジュツメン)** 89 | 90 | **[Metronomeの収益コントラクトと自動交換コントラクト](#metronomeノシュウエキコントラクトトジドウコウカンコントラクト)** 91 | 92 | **[トークン供給の経済学](#トークンキョウキュウノケイザイガク)** 93 | 94 | > [理論](#theory) 95 | > 96 | > [供給スケジュール](#supply-schedule) 97 | > 98 | > [Metronomeの中核](#metronome-core) 99 | > 100 | > [トークンのAPI](#token-api) 101 | > 102 | > [オークションのAPI](#auction-api) 103 | > 104 | > [Metronome収益コントラクト](#metronome-proceeds-contract) 105 | > 106 | > [収益コントラクトのAPI](#proceeds-contract-api) 107 | > 108 | > [Metronome自動交換コントラクト](#metronome-autonomous-converter-contract) 109 | > 110 | > [自動交換コントラクトのAPI](#autonomous-converter-contract-api) 111 | > 112 | > [TokenLocker](#tokenlocker) 113 | > 114 | > [TokenLockerのAPI](#tokenlocker-api) 115 | > 116 | > [TokenPorter](#tokenporter) 117 | > 118 | > [TokenPorterのAPI](#tokenporter-api) 119 | 120 | **[コントラクトの用語集](#glossary-of-contract-terms) ** 121 | 122 | **[付録A](#appendix-a) ** 123 | 124 | 表と図の一覧 125 | ========================== 126 | 127 | 図1：米ドルとBTC貨幣を基にした比較 11 128 | 129 | 図2：Metronomeコントラクト間の流れとインタラクション 12 130 | 131 | 図3：クロスブロックチェーンのポータビリティの図解 15 132 | 133 | 図4：人気のある暗号通貨の造幣 18 134 | 135 | 図5：ビットコインとMetronomeの造幣と供給 19 136 | 137 | 図6：ZECとMET間の作者の保持の比較 20 138 | 139 | 表1：今日の暗号通貨間の 140 | 重要な属性の比較 21 141 | 142 | 図7：自動交換コントラクトの仕組み 22 143 | 144 | 表2：供給スケジュール 27 145 | 146 | 147 | 148 | モチベーション 149 | =========== 150 | 151 | Metronomeの開発において、Metronomeの作者は過去の暗号通貨から学んだ教訓を生かして、唯一の目的が長命の通貨システムであるような暗号通貨を構築するという大志を抱きました。これを念頭において、Metronomeの作者は、以下に新しい機会を見出しました。 152 | 153 | - 経済的に持続性のあるものを設計する 154 | 155 | - 分散型の金融製品を自動実行させる 156 | 157 | - トークン配布への平等なアクセスを確実にする 158 | 159 | - 自動、セルフガバナンスのコントラクトを確実にする 160 | 161 | - 暗号通貨を文字通り次のレベルへ持っていく 162 | 163 | **経済的に持続性のあるものを設計する** 164 | 165 | 暗号通貨の中には、造幣が静的であるか、または時間が経過するにつれゼロになるものがあります。ビットコイン[^1]、[^2]およびライトコインのように、[^3]長期的な生存能力についてエコノミストが疑問を投げかけるものが後者です。[^4]、[^5]、その他の暗号通貨のトークン供給は、特定の関係者に巨大な額の供給を与える、新規暗号通貨公開前のディールにしっかりと結び付けられており、それらの関係者が過半数のトークンを制御する結果を招きます。暗号通貨の中にはプリセールまたは未公開セールで売り切れになり、一般人にはほとんど残っていないものがあります。Metronomeでは、継続したトークン供給の造幣を永久的に提供する 166 | 日次オークションによってこれらの問題に対処しようとしています。継続したトークン供給の造幣は、造幣がゼロであるか、ゼロになるその他の暗号通貨に比べてサステナビリティを提供すると理論化されています。[^6]、[^7]Metronomeチームでは、これによりMET保有者がMetronomeの数多くの支払い機能を活用することが促進されることを期待しています。これらの使用ケースを活用して、実際に暗号通貨を通貨として使用することは、 167 | その耐久性を確実なものにすると考えられます。Metronomeチームでは、継続した造幣により、ある時点で購入される不均衡な金額も希釈されると信じています。Metronomeによって、長く継続するものを設計していると確信しています。長命はMetronomeの主要な目標です。 168 | 169 | **分散型の金融製品を自動実行させる** 170 | 171 | 分散型のシステムを自動実行させてセルフサステインにすることは新しいことで、サイエンスよりもアートです。Metronomeは新しい分野を切り開こうとしています。Metronomeのオークションからの収益はすべて2つの別々のスマートコントラクトに送られます。[^8]これらのコントラクトは、METを売りたいオーナーに流動性を提供するように設計されています。[^9] 172 | 173 | Metronomeチームでは、すてべのオークション収益をMetronomeエコシステム内に留めることにより、Metronomeは成長すると予期しています。さらに、チームは他者が彼らのプロジェクトおよび製品のためにMetronomeのモデルを研究するようになると考えています。 174 | 175 | **トークン配布への平等なアクセスを確実にする** 176 | 177 | Cryptocurrency should be more egalitarian. More than just the 1% should have access to the world\'s next cryptocurrency. Distributing access to the cryptocurrency widely to the public reduces the number of stakeholders with large percentage stakes compared to the entire Metronome economy. 178 | 179 | 競り下げ式オークションは、購入者が適切であると考える価格でトークンを配布することを目指しています。[^10]他社の新規暗号通貨公開のトークン配布は予め設定されており、しばしば一般人がアクセスする前にプリセールや非公開セールでほとんどが売りれてしまいます。[^11] 180 | 181 | Metronomeでは、初期供給オークションと日次供給ロットの両方に競り下げ式オークションを使用するので、一般人がすべてのオークションにアクセスできます。[^12]プリセールやホワイトリスト、ボーナスは存在しません。Metronomeのオークションに参加している人は皆、他の参加者と同じルールで運営する必要があります。つまり、特定の価格で購入するか、または価格が下がるのを待ちます。これらの公開オークションではこのルールから免除されたり、特権を持ったりする人は誰もいません。[^13] 182 | 183 | Metronomeチームでは、初期供給オークションをこのようにして行うことで、「クジラ」や大手のプレイヤーがオークションで大量のMETを買い込むことを思いとどまらせることができると確信しています。不均衡なほど大量のMETにアクセスすることは市場価格より高い価格で購入することになります。その一方で、購入者のコミュニティ内に公平な分配を促進できると信じています。Metronomeでは、短期間の相場師のクイックポップを求めているのではなく、むしろ初期供給オークションのすべての面において公平なアクセスとMETのより適切な分配を提供することを追求しています。 184 | 185 | 186 | **自動、セルフガバナンスのコントラクトを確実にする** 187 | 188 | 人間は誤りを逃れることはできません。ソフトウェアと数学はより予測可能なオーダーであり、より将来志向です。アルゴリズムには政治的意義がなく、人間の思慮分別で通貨が極端つり上がったり、操作されたりしません。自動、セルフガバナンスコントラクト[^14]により、人間の思慮分別で暗号通貨の価値に影響を与える人がいません。この目標を達成するために、Metronomeのスマートコントラクトの所有権機能は、ローンチの後ロックダウンされ、誰もそれらの所有権を持つことができません。Metronomeは完全に自動になります。 189 | 190 | Metronomeは自己調整およびセルフガバナンスであるように設計されました。そのために、Metronomeのコントラクトは完全に自動で、作者の介入なく予測されたように動作すると確信しています。 191 | 192 | 暗号通貨を文字通り次のレベルへ持っていく 193 | ---------------------------------------------------- 194 | 195 | その他の暗号通貨はすべて1つのブロックチェーンネットワークに連結されています。LTCは、ライトコインのブロックチェーン上にのみ記録されます。BTCは、ビットコインブロックチェーン上にのみ記録されます。ただ1つの鉄道に連結されていることには、管理の不調和や不確実な供給などのリスクが伴います。市場では、クロスブロックチェーンが可能であることは知られておらず、その必要性については全く理解されていません。 196 | 197 | Metronomeは、永久に1つのブロックチェーンに結合されていない最初の暗号通貨です。これは、1つのブロックチェーンへの終身の委託なく、ベストなブロックチェーンネットワークによってセキュリティ保護されている可能性を持つ最初の暗号通貨です。これは、革新的な暗号通貨の世界でも完全に新しい概念です。 198 | 199 | 200 | 201 | エグゼクティブサマリー 202 | ================= 203 | 204 | Metronome（以下「Metronome」または「MET」）は新しい暗号通貨で、機関レベルの耐久性を持つように設計されています。Metronomeには、ビットコインやイーサリアムなど、他の暗号通貨から学んだレッスンが反映されており、今後100年以上にわたり使用されるように設計されています。 205 | 206 | Metronomeは同等の機会でアクセスできるものとして一般にローンチされます。ローンチ後、Metronomeには設立者の特権が全くなく、トークン供給が予期可能で信頼性があるという特徴を備えています。 207 | 208 | Metronomeのトークン供給： 209 | 210 | - 10,000,000 METの初期供給 211 | 212 | - 8,000,000 MTNは、以下に詳細が説明されているように公開の競り下げ式オークションによって配布されます 213 | 214 | - 2,000,000 MTNは、設立者の保有分（20%）として設立者に配布されます 215 | 216 | - 特別のTokenLockerコントラクトに対して造幣されます（APIセクションを参照） 217 | 218 | - 25%は初期供給オークションの最後に作者が使用できるようになります 219 | 220 | - 残りの75%は12分の1ずつ12四半期にわたり利用できるようになります 221 | 222 | - Metronome作者のみが上記の特定時にTokenLockerコントラクトから撤回することができます 223 | 224 | - 日ごとの新規MET造幣 225 | 226 | - 日ごとに造幣されるMETは公開の競り下げ式オークションによって配布されます 227 | 228 | - 日ごとの造幣量は（i）1日につき2,880 METまたは（ii）1年あたりの未発行のMET供給量の2.0000%と同等の年率 229 | 230 | Metronomeの中核となる設計方針は、セルフガバナンス、信頼性、およびポータビリティの3つです。これらの点によって、Metronomeは独自で永続性があります。 231 | 232 | - **セルフガバナンス** 233 | 234 | - ローンチ後は設立者の不適当な影響がなく、スマートコントラクトによる自動的なセルフガバナンス 235 | 236 | - 個人間またはコミュニティの不和、不一致、誤解に抵抗力がある 237 | 238 | - すべての販売機会への一般公開 239 | 240 | - 100%オンチェーン、分散化、監査可能 241 | 242 | - 競り下げ式オークションによる価格設定 243 | 244 | - **信頼性** 245 | 246 | - 予測可能なトークン供給 247 | 248 | - 新しいMETトークンは、（i）1日につき2,880 METを上回るか、（ii） 1年あたりの未発行のMET供給量の2.0000%と同等の年率で無期限に毎日造幣 249 | 250 | - 新しいトークン供給は安定性があり予測可能で、無期限の造幣 251 | 252 | - 予測可能な価格設定のために設計されている 253 | 254 | - **ポータビリティ** 255 | 256 | - クロスブロックチェーンのポータビリティにより、異なるコントラクトやチェーン間で証明可能なエクスポートとインポートが実現 257 | 258 | - ガバナンス上の問題や不安定性に対する暗号通貨の保護を強化 259 | 260 | - 新しいチェーンのエクスポートとインポートの機能をコミュニティで開発 261 | 262 | - レジャー技術プラットフォームが成熟するにつれ、将来のブロックチェーンへの移行パスを実現 263 | 264 | - **その他の機能** 265 | 266 | - 最初の決済が15～30秒で完了 – 決済時間は下にあるブロックチェーンを基にしている 267 | 268 | - 一括送金 -- 複数の支払いを一括支払いで送金可能 269 | 270 | - サブスクリプション -- ユーザー間で定期的な支払いが可能 271 | 272 | - ERC20は追加のカスタム機能に準拠 273 | 274 | このマニュアルでは、世界で最初のセルフガバナンス、クロスブロックチェーン暗号通貨として上記の基準を満たす新しい暗号通貨であるMetronomeを提案しています。我々は、暗号通貨とその他のトークンコミュニティが独自の用途を考案することを予期しています。 275 | 276 | そのためにも、そしてセルフガバナンスのためにも、Metronomeの作者たちは初期オークション後Metronomeトークンに対する特権を持ちません。Metronomeでは、初期オークションと日次供給ロットの両方に競り下げ式オークションを使用して、購入者が適切であるとみなす価格で購入する機会を購入者に与えます。 277 | 278 | 279 | 背景 280 | ========== 281 | 282 | ブロックチェーンテクノロジー 283 | --------------------- 284 | 285 | ブロックチェーンは暗号化でセキュリティ保護された新しいタイプの記録保持テクノロジーで、金融分野に多大な影響を与えています。これは分散化されており、通常、エコシステム全体におけるすべてのユニットの分散型の元帳会計です。ネットワーク全体にわたる公開台帳と完全な台帳は同期され、お互いに一致する必要があります。これらは、ノードと呼ばれます。ノードによりブロックチェーンユニットの「二重支払い」を防ぐことができると共に、ネットワーク上のブロックのトランザクションを検証することができます。 286 | 287 | ブロックには取引データ、前のブロックのハッシュ、ターゲットハッシュ、およびナンスと呼ばれる値が含まれています。これらのブロックをノードが検証する場所で、マイナーはナンスを発見しようと試みてそれらをブロックチェーンに書き込みます。ナンスはブロック内のすべてのデータのハッシュをターゲットハッシュと一致させます。マイナーの努力と計算力は、新しく造幣された暗号通貨の報酬によって報われます。 288 | 289 | ブロックチェーンの「チェーン」は、マイナーが分散型の公開台帳に書き込む、マイニングしたブロックの途切れのないラインを指します。マイナーが新しいブロックを見つけるためには、前のブロックからのデータを組み入れて、暗号通貨の開始まで遡ることができる履歴を作る必要があります。 290 | 291 | 暗号通貨 292 | -------------- 293 | 294 | 暗号通貨は、暗号技術を使用して新しい通貨の供給を規制するデジタル通貨です。しばしば、新しい発行は上記で説明したマイニングプロセスでブロックを発見したことに対する報酬です。暗号法では、所有者が変わった資金の正当性も検証します。取引を行うユーザーが所有する秘密鍵によってのみウォレット間の資金の転送を承認できます。これらの取引はブロックチェーン上で見ることができ（上記を参照）暗号鍵の使用によりユーザーが資金を送信する意志があり、取引に十分な資金を所有していることが確実になるので、第三者が資金をアカウント間で転送してそれを検証する必要性が減少します。暗号技術が手形交換所やその他の仲介者 295 | の役割に取って代わります。そのため、法定通貨と比べ暗号通貨には貨幣の供給や発行においてより多大な予測可能性を提供する可能性があります。 296 | 297 | 法定通貨の発行と供給が発行当局によって広範囲に管理される場所では、暗号通貨は設計されたようにのみ機能することができます。これが、法定通貨の貨幣供給を予測するよりも容易く、暗号通貨の貨幣供給と造幣率を予測できる理由です。 298 | 299 | ![図1：米ドル貨幣とビットコイントークンを基にした比較](img/figure-1.jpg) 300 | 301 | *図1：米ドル貨幣と人気のある暗号通貨（ビットコイン）トークンを基にした比較 302 | *[^15] 303 | 304 | ビットコイン以降、同様であり、かつ似ていないその他の暗号通貨が作成されました。これらの暗号通貨が集合的にアクティブで動的な市場を構成しています。 305 | 306 | 競り下げ式オークション 307 | ------------------------- 308 | 309 | 現在、ほとんどの新しい暗号通貨では典型的な販売によって初期支払いを提供しています。これらの販売には、ボーナス、早期購入者のための特別価格設定、および購入者が供給をすべて買うことを促進するためのその他の誘引策が含まれる場合があります。これらの誘引策は助けにはなりますが、売り切れを保証するものではなく、不規則な公開アクセスを招く傾向があります。このモデルは、長命を主な目標とする暗号通貨ではうまく機能しません。Metronomeチームでは、このパターンの回避を目指して異なる方法を使用することにしました。 310 | 311 | Metronomeチームでは、興味深い機会とMETのより公平な配布を提供することができる競り下げ式オークションを初期供給オークションと日次供給ロットのモデルとして使用することに決定しました。競り下げ式オークションでは、価格は高い初期価格で開始します。オークションが進むにつれて、すべてのユニットが売り切れるか、事前設定の最低価格に到達するか、オークション期限に到達してオークションが終了するまで、価格は低下します。各購入者は購入時に適正だと考える価格を支払うので、迅速に市場価格を見つけることができ、公平だと確信しています。[^16]購入者が価格が高すぎる、または不適切だと考える場合は、同意できるレベルまで価格が下がるのを待って、供給が残っていれば購入することができます。 312 | 313 | Metronomeチームでは、クジラが不相応な量のMET供給を制御するのを軽減し、オークションの機会への同等のアクセス与え、METのより公平な配布をすることを目標に、このメカニズムを選択しました。 314 | 315 | 316 | 317 | Metronomeについて 318 | ===================== 319 | 320 | Metronomeは新しい暗号通貨で、セルフガバナンスと長命、長期間に渡る信頼性、そして最大のポータビリティに適するように設計されています。企業上レベルの耐久性を持つように設計されているMetronomeには、これまでに作成されたその他の暗号通貨から学んだレッスンが反映されており、今後100年以上にわたり使用されるように設計されています。我々はMetronomeは1,000年続く暗号通貨であると確信しています。 321 | 322 | Metronomeの仕組み 323 | =================== 324 | 325 | ![図2](img/figure-2.jpg) 326 | 327 | *図2：イーサリアムブロックチェーンについてのMetronomeコントラクト間の流れとインタラクション* 328 | 329 | **ローンチ** 330 | 331 | より公平でオークションとMET供給へのより平等なアクセスを提供するという、Metronomeチームの目標の一環としてMetronomeの初期供給オークションと日次供給ロットには競り下げ式オークション（DPA）が使用されます。このモデルは典型的なオークションと異なるので、ここで説明します。競り下げ式オークションでは、トークンあたりの価格は最高価格から始まります。すべての供給が購入済みになるか、オークション期限に到達してオークションが終了するまで、価格は徐々に下がります。Metronomeには、透明性と予測可能性のある価格設定を確立するためにDPAが使用されます。 332 | [^17] 333 | 334 | 初期供給オークションにおける開始価格は、METにつき2 ETHです。オークションがオープンで購入できるMETが存在する限り、価格は60秒ごとに0.0001984320568 ETHずつ最低価格である0.0000033 ETHまで下がります。 335 | 336 | 購入者はMetronome暗号通貨をリアルタイムで購入し、購入後ほとんど即座にMetronomeを受け取ります。日次供給ロット中に購入したMetronomeは受け取り次第、即座に転送できますが、初期供給オークション中に購入したMetronomeは、初期供給オークションがクローズするまで譲渡することはできません。 337 | 338 | Metronomeチームでは、オークションをこのようにして行うことで、適切だと考える価格でMETを購入する機会を、その価格で購入できるMETが存在する限り、購入者に提供することができると確信しています。Metronomeチームでは、競り下げ式オークションは「すべての人が最終価格」を支払う純粋なダッチオークションと比べてより正確な市場価格になると考えています。これは、単に購入者が喜んでその価格より高い価格を払う場合に最終価格は継承的に価値以下になるからです。 339 | 340 | 不均衡に大量のMETを購入すると、新興市場の価格よりもより価格が高くなる可能性があるため、この方法は、「クジラ」や大手のプレイヤーがオークションで大量のMETを吸い込む機会を減らすことができます。それでも純粋なダッチオークションでは、METが不均衡に早期の購入者に配布されます。 341 | 342 | 多くの供給/購入シナリオが可能ですが、強調したいことは「a slow trickle followed by a sudden waterfall（ちょろちょろとした流れには突然の滝が続く）」です。このシナリオでは、購入者は少数の供給をより高い価格で購入します。一旦、価格があるしきい値未満に下がると、残りの供給は急速に買い取られる可能性があります。 343 | 344 | **フェーズ1：初期供給オークション** 345 | 346 | - 初期トークン供給には、10,000,000のトークンが割り当てられています。 347 | 348 | - 初期トークン供給の20%は設立者によって保持されます。 349 | 350 | - 特別のTokenLockerコントラクトに対して造幣されます（APIセクションを参照） 351 | 352 | - 25%は初期供給オークションの最後に作者が使用できるようになる 353 | 354 | - 残りの75%は12分の1ずつ12四半期にわたり利用できるようになる 355 | 356 | - Metronome作者のみが上記の特定時にTokenLockerコントラクトから撤回することができる 357 | 358 | - 8,000,000（合計初期トークン供給である10,000,000 METから設立者によって保持される20%のトークンを差し引いたもの）のトークンの競り下げ式オークション 359 | 360 | - 初期供給オークションは7日間継続されます。 361 | 362 | - 初期供給オークションの価格は、METにつき2 ETH、最低価格は0.0000033 ETHに設定されています。 363 | 364 | - 初期供給オークションでは、60秒ごとにMETオークションの価格が0.0001984320568 ETHずつ直線状に下がります。 365 | 366 | - オークションは、8,000,000のトークン在庫が完全に売り切れるか、オークションが7日間（10,080分）後に終了するまで続きます。 367 | 368 | - 初期オークションの収益は100%収益コントラクトに格納されます。 369 | 370 | **フェーズ2：運営通貨** 371 | 372 | - 前のオークションの終了時から24時間ごとに、（i）1日につき2,880 METを上回るペースか、（ii）1年あたりの未発行の供給量の 2.0000%と同等の年率で、新しいトークンが日次供給ロット（DSL）に無期限で追加されます。 373 | 374 | - 24時間ごとに、オークションが開始され、オークションのオーバーラップを避けるために24時間未満継続します。 375 | 376 | - 日次供給ロットにある全トークンの競り下げ式オークションは前のオークションの最終価格の2倍である最高価格で開始されます（*例* オークションが売り切れになった場合は最後のトークンの価格、またはオークションが時間切れになった場合はその時の価格） 377 | 378 | - ある日次供給ロットでMetronomeが全く売れなかった場合、次の日の日次供給ロットの価格は、Metronomeが*日次供給ロットのオークションで最後に購入された*価格の1/100で開始されます。 379 | 380 | - 60秒ごとに、オークションの価格は前の価格の99%に下がります。 381 | 382 | - オークションは、（i）日次供給ロットの在庫が売り切れになる、または（ii）オークションの24時間の期間が終わるのいずれかが生じるまで継続します。 383 | 384 | - 日次供給ロットの在庫が完売にならなかった場合は、残りのMETは次の日の日次供給ロットに追加されます。 385 | 386 | - 日次供給ロットのオークションの絶対最低価格は1 Weiです。 387 | 388 | - 日次供給ロットの収益は、100%収益コントラクトに行きます。 389 | 390 | - 24時間ごとに、収益コントラクトの集計合計の0.25%が自動交換コントラクト（以下を参照）に送られ、MET所有者が希望する場合、METを売却する追加のオプションを提供します。 391 | 392 | クロスブロックチェーンのポータビリティ 393 | ---------------------------- 394 | 395 | 396 | ![図3](img/figure-3.jpg) 397 | 398 | *図3：クロスブロックチェーンのポータビリティの図解* 399 | 400 | Metronomeの独自の特徴の1つにクロスチェーンのポータビリティがあります。このポータビリティにより、ユーザーはいかなる理由でも自分のMETをあるブロックチェーンから別のブロックチェーンに移動させることができます。ユーザーが自分のMETを移動させることにした場合、ユーザーはMETの移動先であるターゲットのブロックチェーンにコミットする必要があります。ユーザーはソースブロックチェーンA上のトークン供給から自分のMETを削除して、「プルーフオブイグジット」マークルレシート[^18]を受け取ります。次に、ユーザーはこのレシートを移動先ブロックチェーンB上でMetronomeコントラクトに提供します。 401 | 402 | このシナリオでは、このエクスポート/インポートプロセスを通して、ブロックチェーンAのMETのトークン供給は減少し、ブロックチェーンBのトークン共有は増加します。自動日次供給ロットは、ブロックチェーンAとブロックチェーンBにわたるMETの新しい配布状態を反映するように、ブロックチェーンAとブロックチェーンB上で安分比例で調整されます。例えば、すべてのMETの50%がそれぞれブロックチェーンAとブロックチェーンB上に存在する場合、ブロックチェーンA上の日次オークションは日ごとに1,440のトークンを造幣し、またブロックチェーンB上の日次オークションも日ごとに1,440のトークンを造幣します。 403 | 404 | エクスポート / インポートシステム 405 | ---------------------------- 406 | 407 | 408 | Metronomeは、他のブロックチェーンの上位にあり、セルフガバナンスの特性を確実にして、さらに耐久性のあるものにします。チェーン性能が欠如すると、グローバル供給のような定数の維持を、単一ブロックチェーンの暗号通貨の場合よりも扱いにくくします。このような理由により、Metronomeのインポートとエクスポート機能は、初めに3つのフェーズで展開されます。ブロックチェーン技術が継続して向上すると、フェーズを追加して、Metronomeエコシステムをさらに分散化および増強することが可能です。 409 | 410 | 高レベルにおける、Metronomeのポータビリティのコンポーネントは次のとおりです。 411 | 412 | **エクスポート** オーナーは、エクスポート機能をコールして、METを1つのチェーンから別のチェーンに移動できます。この機能は、マークルレシートの形式で、ユーザーのMETを取得し、ローカルチェーンでこれをバーンし、ユーザーにExportReceiptを与えます。オーナーは、METで少額の料金を支払います。これは検証者によって請求されます。このレシートは、移動先チェーンでMETを請求するのに使用できます。これにより、オーナーのMETを開始チェーンから移動先チェーンに効率的に移動できます。 413 | 414 | **インポート** すべてのユーザーは、ExportReceiptを指定の移動先Metronomeコントラクトに提供できます。これらは、importMETをコールして、ExportReceiptを提供します。処理の際、移動先チェーンはMETを元の受領者に提供します。Metronomeインポートを完了したユーザーは、認証のためにMETで上記の料金を受領します。 415 | 416 | ただし、Metronomeはマルチチェーンなので、これらのチェーンにわたる分散型の真のソースになります。ここでは、検証がインポートとエクスポートで役割を果たします。 417 | 418 | **検証** インポートとエクスポートの裏で、検証者は、次が要求されます。 419 | 420 | ハードフォークの場合、チェーンが有効がどうかを認証 421 | 422 | 特別なインポートの検証のために、追加情報を提供（イベントプルーフなど） 423 | 424 | Metronomeのインポート/エクスポートインフラストラクチャは、3つのフェーズで展開されます。Metronomeは、v1でローンチし、将来のアップグレードは、既存のMetronomeコントラクトにプラグインされます。 425 | 426 | 検証者は、他の暗号通貨における「マイナー」と似たMetronomeエコシステム内で概念的に役割を果たします。これらは、Metronomeの分散型の真のソースを検証および認証します。エクスポーターは、これらの努力に対して検証者にMETでオプション料金を支払います。 427 | 428 | 検証フェーズのシステム設計（以下）の目的は、次を保証することです。 429 | 430 | Metronomeのグローバル供給は、日次10,000,000 + 2880を超えません（または1年につき未発行供給の2%で、いずれか大きい方）。 431 | 432 | 検証者は、個々のトランザクションを検閲できません。 433 | 434 | 検証者が、互いに食い違うことは推奨されません（以下を参照）。 435 | 436 | 他のチェーンのMetronomeコントラクトは、食い違いを検出して、安全でないブロックチェーンに「フラグ」を立て、最終的に、これらが認識された問題を修正するまで保証します。 437 | 438 | 検証フェーズ 439 | ---------------------------- 440 | 441 | フェーズ1検証者は、各ExportReceiptをExportReceiptのハッシュ経由で確認および検証します。十分な数の検証者が、提供されたハッシュが有効と認めると、だれもが検証済みのレシート経由でMetronomeのインポートを完了できます。 442 | 443 | フェーズ2検証者は、すべてのExportReceiptの履歴リストを保持し、レシートのハッシュから成るマークルツリーを作成し、これらのツリーのマークルルートを検証します。次に、インポーターは、検証者とユーザーのインポートのプルーフを提供します。インポートのプルーフは、イベントのルートを認証する、マークルレシートと一対のハッシュから成ります。 444 | 445 | フェーズ3検証者は、Metronomeが存在する各チェーンのブロックチェーンハッシュを検証します。インポーターは、次のプルーフを提供します。 446 | 447 | - エクスポートイベントが、マークルパスを通して、エクスポートチェーンの、特定のブロックヘッダーにあるというプルーフ。 448 | 449 | - ブロックイベントが検証済みのチェーンハッシュに対応するというプルーフ。 450 | 451 | 不正アクターの保証と安全対策 452 | ---------------------------- 453 | 454 | 信頼されたアクターを備えたフェーズ1検証モデルは、それ自体を証明するので、コミュニティやチームは、継続して検証メカニズムで、さらなる分散化を行えます。現在、最も好ましい分散化レベルは、フェーズ3の後になるでしょう。検証モデルのより優れた分散化は、多くの方法で安全性を追加しますが、依然として、アクターが「非合理的な」理由で不正に動作する可能性があります。これに対抗するために、システムアーキテクチャは、面倒な行為、チェーンからチェーンへの攻撃、Metronomeの他のセットにおけるバグ、様々な他の詐欺やエラータイプの問題に柔軟でなければなりません。 455 | このシステムは、まだ規定の途中ですが、大まかに言えば、いくつかのプルーフオブワーク（Proof of Work）のコンセプトを合わせた、より良いプルーフオブステーク（Proof of Stake）システムを基にしたコアコンセプトを使用します。Metronomeは、不正アクターに対するシフトとハードの結果双方を保有する計画です。Metronomeの基本ルールは、常に、供給が固定され、ユーザーがどのMetronome領域の部分が安全かを知り、これらのMETを安全な場所にエクスポートできることです。 456 | 457 | 458 | 分散型、自発的合意ガバナンス 459 | ------------------------------------------- 460 | 461 | Metronomeを作者によってローンチされた初期の「創世記」チェーンからエクスポートする機能、およびMET保持者のコミュニティの自主的な合意を基にして作者やその他の者によってリリースされたその後のアップグレードをインポートする機能により、イミュータブルのコントラクトと公平な分散型メカニズムの両方に市場が熟するにつれてこれらのコントラクトをアップグレードする機会が提供されます。 462 | 463 | 例えば、市場の需要が供給を大幅に上回り、METのオリジナルの実際価格がマーチャントにとって実際的である価格を超過して上昇した場合、制御している資金をエクスポートすることによって、同一または異なるチェーン上の新しいMETコントラクトでMET供給をフォークすることに同意することができます。新しいイミュータブルのMETコントラクトがより幅広い商用目的にトークン供給をアップグレードしたことになるので、これらのダイナミックスはトークン供給曲線の先験的設計からリスクを取り除く潜在性があります。 464 | 465 | 同様に、ある一定期間、市場の供給が需要を超過し始め、価格が下落している場合は、異なるMETフォーク上の保持者は複数のエクスポートソースから単一のインポート先に「マージ」することに同意することができます。この自主的合意のメカニズムを介して経済的にアクティブなMETの供給全体を減らすことにより、需要が減少にした場合にトークン供給を減少させて安定した価格を維持します。 466 | 467 | フォークと新しいチェーンへの移行がMETトークン供給曲線と発行にどのような影響を与えるかは、Metronomeコミュニティにとって未解決問題です。自分で新しいMETターゲットコントラクトの定義、実装、フォーク、マージに参加して、METを新しいコントラクトへインポートして何が起こるか見てみてください。 468 | 469 | 470 | 今日の暗号通貨の市場環境 471 | ===================================== 472 | 473 | Metronomeがどのように暗号通貨の世界に適合するかをよりよくご理解いただくためには、全体の状況を展望する必要があります。 474 | 475 | 活動状況 476 | ------------- 477 | 478 | いくつかのよく知られている暗号通貨、トークン供給割り当て、発行スケジュール、経済的回復力、そのスケジュールの可変性に対する抵抗力について検討してみましょう。 479 | 480 | ![図4](img/figure-4.jpg) 481 | 482 | *図4：今日の人気のある暗号通貨の造幣、注：ETHは予想です*[^19] 483 | 484 | ビットコイン（「ビットコイン」または「BTC」）は、マイニングとエコシステムへの参加へパブリックが平等にアクセスできるということで2009年1月5日に開始されました。[^20]新しい通貨供給は各ブロックに追加されます。ブロック期間は、2,016ブロックにつき10分/ブロックに目標が定められています。造幣される供給はブロックにつき50 BTCで、4年ごとに半減します。 485 | 486 | ビットコインコミュニティでは、ビットコインの2,100万の通貨供給制限の不変性と発行スケジュールの不変性に高い価値を見出しています。一旦、制限に到達すると、新しいBTCのマイニングは停止され、うまくいけば取引料金がマイナーにインセンティブを与えることになっています。供給発行がごく少量のレベルになったときに、取引料金がビットコインに資金を十分もたらし、安全に保つのに十分であるかどうかについては、ビットコインコミュニティで幅広く議論されています。[^21] [^22] ビットコインが今日ゼロから再び開始されるとしたら、現在の絶対的なデフレ的な性質が永続するマイルドなインフレの特徴によって置き換えられ、マイナーが将来に向けて無期限にネットワークを保証するインセンティブを与えるでしょうか。おそらく。リソースの買いだめをやめさせるので、低レベルのインフレーションは理想的で、*暗号通貨による投資を促進させ*マイニングによるブロックチェーンの保証が続きます。[^23] 487 | 488 | ![図5](img/figure-5.jpg) 489 | 490 | *図5：ビットコインとMetronomeの造幣と流通供給*[^24] 491 | 492 | 発行スケジュールの予測可能性と不変性が、現在のユーザー頼りにするものです。予測可能性により、市場のユーザーは将来に向かって何年か先、おそらく何十年先を計画することができるようになります。不変性により、通貨供給が人間の気まぐれや脆さによって変更されないことが確実になります。ただし、ビットコインには、ネットワークガバナンスに影響を与えることに関心を持っているグループが各種あり、論議をかもし出すフォーク、不確実性、および見世物などでコミュニティを混乱させています。 493 | 494 | ライトコイン（「Litecoin」または「LTC」）は、ビットコインを手本として作成されています。[^25]ブロックは、ブロックにつき2.5秒を目標としています。 造幣される供給はブロックにつき50 LTCで、4年ごとに半減します。ライトコインは、通貨の発行面に関しては大部分がビットコインのコピーで、発行スケジュールはコミュニティの大多数によってイミュータブルであると推定されています。 新しい供給発行は、ビットコインと同様に時間の経過と共に減少します。ライトコインのガバナンスはビットコインと同様ですが、そのエコシステムにおけるアイコンに対して慣例的な敬意を払う点があります。 495 | 496 | Zキャッシュ（「Zcash」または「ZEC」）は、同様に機能します。プルーフオブワークのマイニングはすべての人に公開されています。ブロック期間は、ブロックにつき2.5分です。造幣される供給は、ブロックごとに12.5 ZECで、4年ごとに半減します。特例として、最初の20,000のブロックは、ゆっくりと開始して完全な12.5 ZECの率に増加されます。1回限りの報酬の代わりに、開発チームとサポートプロトコル開発はトークン供給の10%の設立者の報酬を受け取ります。これは、ローンチから4年後、最初の半減期まですべてのブロックに適用されます。その時点後は、造幣されるトークン供給の100%がマイナーに支払われます。[^26] Zcash Foundationでは、エコシステムの自主的ガバナンスが自然の軌道をたどることを意図しています。[^27] 497 | 498 | ![図6](img/figure-6.jpg) 499 | 500 | *図6：流通供給に対するZECとMET間の 501 | 作者の保持の比較*[^28] 502 | 503 | イーサリアム（「Ethereum」または「ETH）のプリセールは60,000,000を超過するETHを集めました。これらは、創世記ブロックに予めマイニングされていました。[^29] [^30] 新しい通貨の供給 -- 5 ETH -- が各ブロックに追加されます。新しい通貨の供給T+1Yは19.8%に、T+2Yは21.2%に、T+3Yは17.4%に増加されました。供給の増加は、それ以降下降します。イーサリアムの通貨発行スケジュールは、流動的であるとの定評があり、システムが進化するにつれて変化する可能性があります。[^31]イーサリアムは、プルーフオブステークに変更する予定で、それにより発行スケジュールが変わります。[^32]そのため、レジリエンスとサステナビリティを目標にして、発行はミュータブルです。変更はコミュニティとマイナーによってサポートされている必要がありますが、まだ少数の設立者チームに対する慣例的な敬意と依頼がかなり見られます。 504 | 505 | リップル（「Ripple」または「XRP」）には、使用可能な供給である380億のXRPがあります。[^33]管理会社であるRipple, Inc.はさらに610億のXRPを所有しており、そのうちの550億のXRPはエスクローに預託されています。[^34]これは、Ripple, Inc.と共に中央管理されており、暗号通貨のエコシステムの大きな部分を制御しています。Ripple Inc.は市場への供給の発行を直接管理するので、XRPはかなりミュータブルです。Ripple Inc.は不均衡なガバナンス権力を保持しています。 506 | 507 | Metronomeでは、これらのデジタル通貨から学んだ教訓を活かして、アーキテクチャーの主要原理として発行、ガバナンス、および信頼性において機関レベルの耐久性がある暗号通貨を設計しました。作者からの過剰な影響がなく100%自動で、セルフガバナンスの設計目標を促進しています。 Metronomeは予測可能で、新しいMETを予測可能なレートで造幣するので、安定しています。また、ユーザーが適切であると考える理由でブロックチェーン間でインポートおよびエクスポートすることができるので、ポータブルです。 508 | 509 | 510 | | | BTC | LTC | ETH | XRP | ZEC | MET | 511 | |--|--|--|--|--|--|--|--| 512 | | **信頼性** | BTCはで異論のあるフォークと通貨収縮的な特質で有名である。トークン供給と発行は安定しているが、制限がある。 | BTCと同様、LTCの発行とトークン供給には上限が設定されており、チェーンの安定性を脅かす可能性がある。 | ETHの発行とトークン供給のモデルは流動的である。過去にフォーク（分裂）したことがある。 | XRPには安定した供給がある。これはRipple Inc.によって完全に管理されている。 | BTCと同様に、ZECには上限が設定されており、将来チェーンのセキュリティが問われる可能性がある。 | **METの発行と供給はコントラクトで定義されているように予測可能で無限である。供給や発行に関して不確かなことは何もない。** | 513 | | **セルフガバナンス** | BTCはセルフガバナンスだが、過度の影響を及ぼそうとしている多くのグループがいる。 | LTCはセルフガバナンスだが、慣例的にアイコンに服従している。| ETHへの変更はコミュニティのサポートが必要だが、小さなチームにあまりにも依存している。 | XRPはセルフガバナンスを行っていない。Ripple IncがXRPのガバナンスの唯一の権力を保持してる。 | Zcash Foundationは、自発的なガバナンスの自然の軌跡である。 | **METは、自動コントラクトを介して完全にセルフガバナンスである。** | 514 | | **ポータビリティ** | なし | なし | なし | なし | なし | **あり** | 515 | | **イミュータビィティ** | 強い | 強い |ミュータブル; PoSで変更 | 弱い | 強い | **強い**| 516 | | **発行モデル** | 10分につき50 BTC。4年ごとに1/2に減少。 | 2.5分につき50 LTC。4年ごとに1/2に減少。 | 15秒につき5 ETH。 | Ripple Incによって一度発行済み | 2.5分につき12.5。4年ごとに1/2に減少。 | **日次METオークション販売は（i）1日につき2,880MTNまたは（ii）1年あたりの未発行のMET供給量の2.0000%と同等の年率のうちいずれか大きな方** | 517 | | **供給上限** | 2,100万 | 8,400万 | 不明 | 1,000億 | 2,100万 | **上記の発行モデルを参照** | 518 | | **決済時間** | 10分 | 2.5分 | 15秒 | 5秒 | 2.5分 | 15秒 | 519 | | **一括払いの機能** | あり | あり | なし | なし | あり | **あり** | 520 | | **サブスクリプション機能** | なし | なし | なし | なし | なし | **あり**[^35][^36][^37][^38][^39] 521 | 522 | *表1：今日の暗号通貨間の 523 | 重要な属性の比較* 524 | 525 | Metronomeのコントラクトと技術面 526 | ========================================= 527 | 528 | 4つの自動スマートコントラクトがMetronomeを構成しています。一般的な流れは次の通りです。 529 | 530 | 1. 最初のコントラクトはMETトークンと台帳で、直接ブロックチェーンとやり取りをします。これは、ユーザーがどのようにピアツーピアの取引を決済するかで、富の分散型保存として使用することができます。これは、向上したセキュリティと転送のためにカスタム機能を備えた、親しみのあるERC20トークン標準です。 531 | 532 | 2. トークンコントラクトの後には、オークションコントラクトが続きます。ユーザーはオークションコントラクトを介してMETを購入します。ユーザーがオークションコントラクトから購入すると、コントラクトがそのユーザーのためにMETを造幣します。 533 | 534 | 3. 次に、オークションコントラクトが収益を3番目のコントラクトである収益コントラクトに送信します。初期供給オークションと各日次供給ロットからの収益の100%がオークションコントラクトから収益コントラクトへ送信されます。 535 | 536 | 4. 収益コントラクトは、24時間ごとにコンテンツの0.25%を4番目のコントラクトである自動交換コントラクトに送信し、利用可能なETHを提供します。ユーザーがETHまたはMETを自動交換コントラクトに送信すると、コントラクトはコントラクトによって定められた変換率でそれぞれMETまたはETHを返します。自動交換コントラクトではトークンの比率によって相対値が決まるので、アービトラージが行われて価格設定がほぼ正確に保たれます。コントラクトのMET（またはETH）が少なすぎる場合、対応するペアに比べてその価格が高くなります。自分が所有しているMET（またはETH）がそれほどの価値がないと考えるユーザーは自分のトークンを取引所で別のトークンに交換します。これにより、コントラクトのコンテンツのバランスがとれ、相対価格の不均衡が修正されます。 537 | 538 | Metronomeの収益コントラクトと自動交換コントラクト 539 | ===================================================== 540 | 541 | Metronomeとそのユーザーにとって永続するエコシステムを構築する目的で、すべてのオークションからの収益はすべてMetronomeエコシステム内に留まります。オークションからのすべての収益がコントラクトのチェーン上に留まることを確実にすることにより、Metronomeがより自発的な長命を保つことができると確信しています。 542 | 543 | この流れは、購入者がオークションからMETを購入するときにやり取りするコントラクトである、オークションコントラクトで開始します。次に、収益コントラクトがオークションコントラクトから収益を受け取り、その一部を自動交換コントラクトにエクスポートし、自動交換コントラクトに購入販売用のETH供給を提供します。初期化された時点では、自動交換コントラクトには1 METが存在します。 544 | 545 | 初期供給オークションとその後の各日次供給ロットでは、収益の100%が収益コントラクトへ送信されます。収益がMetronome作者たちに配布されることは全くありません。各日、収益コントラクトは蓄積された収益合計の0.25%を自動交換コントラクトに転送します。これにより、自動交換コントラクトに単にレシートを配置することと比較した場合、日々のオークション量における変動を平均化することができるというのが我々の期待です。 546 | 547 | ETHを自動交換コントラクトに販売すると、ETHの特定額に対するコントラクト内の入手可能なMETの価値が上昇します。誰かがMETを売ってETHを買う場合、より多くのETHを取得し、誰かが自動交換コントラクトを使ってMETを購入する場合、それに対してより多くのETHを支払う必要があります。 548 | 549 | 自動交換コントラクトにおける日々のETHの販売により、市場がサポートできるレベルを越えてMETの価値が上昇するので、アービトラージによって過剰ETHが捕獲されると確信しています。ただし、Metronomeの予測可能性は何十年という時間の尺度で計られていることを考えると、市場は自動交換コントラクトへの利用可能なETHの流れにおいて予測し価格設定することも考えられます。 550 | 551 | ![図7](img/figure-7.jpg) 552 | 553 | *図7：自動交換コントラクトとのやり取りにおけるユーザーの体験と自動交換コントラクトのバックエンドプロセス* 554 | 555 | **経済上の予測** 556 | 557 | 自動交換コントラクトが市場によって決定される価格を探求する一方、オークションコントラクトには各日固定された価格スケジュールがあります。その結果： 558 | 559 | - オークションのトークン価格が自動交換コントラクトの価格より高いときは、購入者がオークションからトークンを購入するのはありそうもないと考えられます。購入者は自動交換コントラクトから価格の安いトークンを買ったほうがいいからです。 560 | 561 | - オークションのトークン価格が自動交換コントラクトの価格よりも低いときは、オークションで購入したトークンを自動交換コントラクトに販売してアービトラージの利ざやを得ることができます。これにより、自動交換コントラクトのETHの不均衡が裁定取引されつくします。ただし、誰もがこれを行うとするので、価格差が著しくなる前にオークションは売り切れになるはずです。 562 | 563 | 要するに、オークションでの購入者は自動交換コントラクトの現在価格に非常に近い価格でオークションのトークンを購入しようとすると考えられ、各日の後の購入者は早い購入者から利益を得ることができ、本質的にオークションで全くトークンを購入できないというリスクの見返りを得ることができます。 564 | 565 | 日次供給ロットが売り切れになると、トークン価格を吊り上げて自動交換コントラクトへ販売することによって過剰需要を満たすことができます。競り下げ式オークションでは価格が最終的には市場価格を下回るので、各オークションは売り切れになると考えています。 566 | 567 | **暗号通貨の数学** 568 | 569 | ユーザーが自動交換コントラクトで取引を行うとき、ユーザーはトークン供給間の比率を不均衡にするので、常に価格の低下が伴います。ユーザーが購入するロットの大小にはかかわらず、すべての価格は方式によって決定され、すべてが同じ結果になります。[^40] 570 | 571 | 2つの数式があります。1つはユーザーがMETまたはETHに対していくつのスマートトークンを取得するかを計算します。もう1つの数式は、ユーザーがスマートトークンに対してどれだけのMETまたはETHを取得するかを計算します。スマートトークンがユーザーに渡されることは決してありません。 572 | 573 | 正確で効率のいい「基本関数」を構築することは重要なエンジニアリングのタスクです。 イーサリアムには256ビット整数しかないので、新しい実装が必要です。 574 | 575 | 自動交換コントラクトを0.5のリザーブ率でMETとETHの2つの暗号通貨に制限することで、演算は簡略化され、平方根のみが必要となります。これは、実装しやすく、実行するのに適度に効率的です。 576 | 577 | 演算は以下の通りです。 578 | 579 | *R* = リザーブトークンの残高 580 | 581 | *S* =スマートトークンの供給 582 | 583 | *F* = 固定準備率 584 | 585 | *T* = リザーブトークンEとの交換で受け取ったスマートトークン 586 | 587 | *E* = スマートトークンTとの交換で受け取ったリザーブトークン 588 | 589 | オリジナルの数式は次の通りです。[^41] 590 | 591 | *T* = *S*((1 + $\frac{E}{R}$)${{}^{}}^{F} - 1$) 592 | 593 | *E* = *R*(1 - (1 - $\frac{T}{S}$)${}^{\frac{1}{F}}$) 594 | 595 | Metronomeの場合、Fは0.5に設定されているので、以下のように数式は固定小数点の乗法、除法、そして平方根になります。 596 | 597 | *T* = *S*($$) - 1) 598 | 599 | *E* = *R*(1 - (1 - $\frac{T}{S}$)${}^{2}$) 600 | 601 | **計算例** 602 | 603 | 自動交換コントラクトに、1000 ETHと2000 MET、そして10000スマートトークンがあるとします。自動交換コントラクトのMETの価格は0.50 ETHです。ユーザーはこれは高い方だと考え、100 METをETHに交換したいと考えます。現在の額面上の価格では、この取引では50 ETHが返されるはずですが、価格下落のためにユーザーは実際にはこれより少ないETHを受け取ります。 604 | 605 | **ステップ1**：100 METをスマートトークンに交換します。 606 | 607 | T?=?S?(v1+ E/R )-1) 608 | 609 | T? = 10000( v1 + 100/2000 ) - 1) = 10000( v1.05 - 1) = 10000(1.0247 - 1) = 10000(0.0247) = 247 610 | 611 | ユーザーは247の新しく造幣されたスマートトークンを受け取ります。スマートトークンの合計供給はこれで10247になります。自動交換コントラクトに保有されているMETの合計供給は、これで2100になります。 612 | 613 | **ステップ2**：247のスマートトークンをETHに変換します。これはコントラクトによって自動的に実行されるので、ユーザーは決してスマートトークンを受け取ることはありません。 614 | 615 | 1000 ETHが数式のリザーブ供給であると仮定します。 616 | 617 | *E* = *R*(1 - (1 - $\frac{T}{S}$)${}^{2}$) 618 | 619 | *E* = 1000(1 - (1 - $\frac{247}{10247}$)${}^{2}$) = 1000(1 - (1 - 0.0241)${}^{2}$) = 1000(1 - .976${}^{2}$) = 1000(1 - 0.953) = 1000(0.047) = 47 620 | 621 | ユーザーは100 METに対して47 ETHを受け取ることになります。 622 | 623 | これで、コントラクトには、953 ETHと2100 MET、あるいは1 METにつき0.45のETHが保持されることになります。METを売ることによって、ユーザーは自動交換コントラクトの価格をETHと比較して下げたことになります。ユーザーは初期価格と最終価格のだいたい真ん中の価格でETHを受け取ります。 624 | 625 | 247のスマートトークンは交換された時点で破棄されるので、スマートトークンの供給は元の10000に戻ります。 626 | 627 | **トランザクション発注の軽減** 628 | 629 | 自分の前に他のトランザクションが実行されないことを前提として、ユーザーは自分の取引の結果を予測することができます。ただし、それを保証する方法はありません。実際、他者がそのユーザーのトランザクションが進行中であるのを見て、自分のトランザクションを発注する場合があります。特定のマイナーはこれを非常に効果的に行うことができます。 630 | 631 | トランザクション発注を軽減するために、我々はユーザーが最低のリターンを指定するように求めます。ユーザーが取引からそれだけのリターンを得ない場合は、その取引はロールバックします。つまり、ユーザーはトランザクションを実行する計算費をまかなうための少額のトランザクション料金のみを支払います。 632 | 633 | 634 | トークン供給の経済学 635 | ====================== 636 | 637 | 理論 638 | ------ 639 | 640 | - 供給の予測可能性により、市場の参加者は12ヶ月、5年間、50年間先の供給を正確に判断することができるようになります。 641 | 642 | - 価格は競り下げ式オークションによって決定されます。 643 | 644 | **供給** 645 | 646 | - 初期供給：競り下げ式オークションによる10,000,000トークン 647 | 648 | - 初期供給後の供給：（i）1日につき2,880 MET、または（ii）1年あたりの未発行供給量の2.0000%いずれか大きな方と同等の年間供給 649 | 650 | - オークションはほぼリアルタイムで決済されます。 651 | 652 | - 皆が限度の価格を支払うので、これによってオークションのベストプライスが発見されると提示している経済学者もいます。[^42] 653 | 654 | ### 供給スケジュール 655 | 656 | | 期間 | 流通MET | 造幣率 | 日次造幣 | 657 | |--|--|--|--| 658 | | T + 1年 | 11,051,200 | 10.512% | 2,880 | 659 | | T + 2年 | 12,102,400 | 9.512% | 2,880 | 660 | | T + 3年 | 13,153,600 | 8.686% | 2,880 | 661 | | T + 5年 | 15,258,880 | 7.399% | 2,880 | 662 | | T + 10年 | 20,517,760 | 5.400% | 2,880 | 663 | | T + 50年 | 63,499,700 | 2.000% | 3,411 | 664 | | T + 70年 | 94,382,561 | 2.000% | 5,070 | 665 | 666 | *表2：供給スケジュール* 667 | 668 | 669 | **APIリファレンス** 670 | 671 | Metronomeの中核 672 | -------------- 673 | 674 | ### トークンのAPI 675 | 676 | METトークンを照会し転送するのに使用されるトークンAPIは、よく知られているERC20トークン標準です。[^43]Metronomeは、カスタム機能を利用して、強化された分散型転送とセキュリティを備えた最新の標準にも対応しています。これらの改良により、転送が受領側のコントラクトの関数を簡単にコールすることができるようにもなっています。これにより、データのみならず値を転送することができ、これはERC20トークン標準のみでは独自にはできなかったことです。Metronomeでは、最先端のテクノロジーが使用されていることを誇りに思っています。 677 | 678 | **ERC20標準** 679 | 680 | | const name | Metronome | 681 | |--|--| 682 | | const symbol | MET | 683 | | const decimals | 18 | 684 | | function totalSupply | ERC20に準拠、ERC20標準を参照。 | 685 | | function balanceOf | ERC20に準拠、ERC20標準を参照。 | 686 | | function transfer | ERC20に準拠、ERC20標準を参照。 | 687 | | function transferFrom | ERC20に準拠、ERC20標準を参照。 | 688 | | function approve | ERC20に準拠、ERC20標準を参照。 | 689 | | function allowance | ERC20に準拠、ERC20標準を参照。 | 690 | | event Transfer | ERC20に準拠、ERC20標準を参照。 | 691 | | event Approval | ERC20に準拠、ERC20標準を参照。 | 692 | 693 | 694 | **カスタムトークン関数** 695 | 696 | 697 | 698 | 699 | 700 | 702 | 703 | 704 | 705 | 706 | 707 | 708 | 709 | 710 | 711 | 712 | 713 | 714 | 715 | 716 | 717 | 718 | 719 | 720 | 721 | 722 | 723 | 724 | 725 | 726 |
Function multiTransfer(uint[] bits)単一のトランザクションにおける複数の転送です。ビット配列の各ユニットが1つの転送を表します。 701 | 左から160ビットがアドレスで、右の96ビットが金額です。
function setTokenPorter(address _tokenPorter) public onlyOwner returns (bool)エクスポートの機能を担うトークンポートのコントラクトを設定します。これはオーナーによってのみ実行することができます。
function mint(address _to, uint _value) public returns (bool)mint（造幣）は造幣者またはトークンポーターによってのみ許可されています。
function destroy(address _from, uint _value) public returns (bool)destroy（破棄）は造幣者またはトークンポーターによってのみ許可されています。
function enableMetTransfers() public returns (bool)この関数はMETの転送を有効にします。初期オークションが終了後にのみ正常に呼び出すことができます。
function export(bytes8 _destChain, address _destMetronomeAddr, address _destRecipAddr, uint _amount, bytes _extraData) public returns (bool)METを別のMetronomeがサポートされているチェーンにエクスポートします。
727 | 728 | **マークル** 729 | 730 | これらの関数は手動使用を意図としていませんが、 731 | 興味深いUI機能の基礎になる可能性があるという考えがあります。 732 | 733 | | Function setRoot(bytes32 root) | msg.senderに関連付けられているマークルルートを設定します。 | 734 | | ------------------------------------------------------------------- | -------------------------------------------------------- | 735 | | Function rootsMatch(address a, address b) constant returns (bool) | 2つのアドレスが一致するルートを持つ場合にはtrueを返します。 | 736 | | function getRoot(address addr) public view returns (bytes32) | アドレスに関連付けられているマークルルートを取得します。 | 737 | 738 | **サブスクリプション** 739 | 740 | これらの関数はMetronomeの独自な機能であるブロックチェーンのサブスクリプションの一部です。ユーザーは、サブスクリプションを介して他のユーザーと他の機関の間に 741 | 関係と繰り返し発生する支払いを促進させることができます。ユーザーは毎週支払いを引き出すことを承認することによってサブスクライブします。次に、 742 | 承認されたグループまたは個人は支払いをユーザーのアカウントから適切と思われるアカウントに支払いを移動させることができます。必要に応じて、ユーザーはサブスクリプションを 743 | キャンセルすることができます。 744 | 745 | これは、過去に他の暗号通貨が困難に直面した問題に対応するものです。マテリアルを基にしてサブスクリプションを支払うことは、 746 | 多くの人気のある暗号通貨では、可能でないか、または煩わしいこととされています。Metronomeのサブスクリプション機能がその問題を解決します。 747 | 748 | 749 | 750 | 751 | 752 | 753 | 754 | 755 | 756 | 757 | 758 | 759 | 760 | 761 | 762 | 763 | 765 | 766 | 767 | 768 | 769 | 770 | 771 | 772 | 773 | 774 | 775 | 776 | 777 | 778 | 779 | 780 | 781 | 782 | 783 |
function subscribe(uint _startTime, uint _payPerWeek, address _recipient) public returns (bool)誰かをサブスクライブする、つまり、その人が毎週支払いを引き出すことを承認します。_startTimeはサブスクリプションが開始するとき。_payPerWeek は小数点以下を含め一週間ごとに支払うべきトークン。_recipientは誰がトークンを引き出すか。
function cancelSubscription(address _recipient) public returns (bool)サブスクリプションをキャンセルします。_recipientは誰のサブスクリプションをキャンセルするか。
function getSubscription(address _owner, address _recipient) public constant returns (uint startTime, uint payPerWeek, uint lastWithdrawTime)サブスクリプション情報を取得します。_ownerが支払う。_recipientはサブスクリプションの受取人。次の情報を返します。startTimeはサブスクリプションが開始されたとき。payPerWeekは受取人が1週間につきいくら引き出すことができるか。lastWithdrawTimeは受取人が最後に引き出したとき。
function subWithdraw(address _owner) public transferable returns (bool)あなたをサブスクライブした誰かから資金を引き出し、successを返します。 764 | _ownerはあなたのサブスクライバー。
function multiSubWithdraw(address[] _owners) public returns (uint)複数のサブスクライバー（_owners）から同時に資金を引き出します。うまく行われた引き出しの数を返します。
function multiSubWithdrawFor(address[] _owners, address[] _recipients) public returns (uint)複数のサブスクライバー（_owners）からそれぞれの受取人（_recipients）へ資金を引き出します。うまく行われた引き出しの数を返します。
event LogSubscription(address indexed subscriber, address indexed subscribesTo)新しいユーザーのサブスクリプションを発信されます。
event LogCancelSubscription(address indexed subscriber, address indexed subscribesTo)ユーザーがサブスクリプションをキャンセルしたときに発信されます。
784 | 785 | ### オークションのAPI 786 | 787 | 788 | 789 | 790 | 791 | 792 | 793 | 794 | 795 | 796 | 797 | 798 | 799 | 800 | 801 | 802 | 803 | 804 | 805 | 806 | 807 | 808 | 809 | 810 | 811 | 812 | 813 | 814 | 815 | 816 | 817 | 818 | 819 | 820 | 821 | 822 | 823 | 824 | 825 | 826 | 827 | 828 | 829 | 830 | 831 | 832 | 833 | 834 | 835 | 836 | 837 | 838 | 839 | 840 | 841 | 842 | 843 | 844 | 845 | 846 | 847 | 848 | 849 | 850 | 851 | 852 | 853 | 854 | 855 | 856 |
Function () payable標準のフォールバック関数。ETHを送信してMETトークンを即座に受け取ります。
function whatWouldPurchaseDo(uint _wei, uint _timestamp) public constant returns (uint weiPerToken, uint tokens, uint refund)ユーザーに_timestamp時点での購入結果がどのようなものかを知らせます。_weiは送信すべきweiのETHの金額、_timestampは予期されるオークション購入のタイムスタンプ。weiPerTokenはその結果の価格、tokensは返されるトークン数、refundはユーザーが取得するwei refundのETH（この購入中にオークションが売り切れ担った場合）
function isRunning() public constant returns (bool)オークションシステムがすでに開始している場合はtrueを返します。
function currentTick() public view returns(uint)現在のブロックタイムスタンプのwhichTickを呼び出します。
function currentAuction() public view returns(uint)whichAuction(currentTick())を呼び出します。
function whichTick(uint t) public view returns(uint)指定されたタイムスタンプtの開始時からのオークションティックを返します。
function whichAuction(uint t) public view returns(uint)指定されたオークションティックtのオークションインスタンスを返します。
function heartbeat() public view returns (bytes8 chain,address auctionAddr,address convertAddr,address tokenAddr,uint minting,uint totalMET,uint proceedsBal,uint currTick, uint currAuction,uint nextAuctionGMT,uint genesisGMT,uint currentAuctionPrice,uint dailyMintable,uint _lastPurchasePrice)現在のオークションについての統計を返します。
function mintInitialSupply(uint[] _founders, address _token, address _proceeds, address _autonomousConverter) public onlyOwner returns (bool)初期展開中に設立者向けの初期供給を造幣するために呼び出されます。これはオーナーのみの関数です。
function initAuctions(uint _startTime, uint _minimumPrice, uint _startingPrice, uint _timeScale) public onlyOwner returns (bool)初期展開中にオークション開始時刻パラメーターを設定するために呼び出されます。これはオーナーのみの関数です。
function stopEverything() public onlyOwner現在のオークションを一時停止させるオーナーのみの関数です。
function isInitialAuctionEnded() public view returns (bool)初期オークションで7日間が経過したか、すべてのトークンが売り切れた場合にtrueを返します。
function globalMetSupply() public view returns (uint)現在のオークション時点での利用可能な供給の合計。
function globalDailySupply() public view returns (uint)現在の日次オークションに利用可能なMETトークンの合計。
function currentPrice() public constant returns (uint weiPerToken)日次オークションでの現在の価格。
event LogAuctionFundsIn(uint amount)オークションコントラクトが資金を受け取ったときに送信されます。
857 | 858 | Metronome収益コントラクト 859 | --------------------------- 860 | 861 | ### 収益コントラクトのAPI 862 | 863 | | event LogProceedsIn(address indexed from, uint value) | 収益コントラクトが資金を受け取ったときに発信されます。 | 864 | | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------- | 865 | | event LogClosedAuction(address indexed from, uint value) | 収益が資金をAutonomousConverterにプッシュしたときに発信されます。 | 866 | | function () public payable | 収益に入ってくる資金を処理します。 | 867 | | function initProceeds(address \_autonomousConverter, address \_auction) public onlyOwner | 初期展開中に呼び出されます。これはオーナーのみの関数です。 | 868 | | function closeAuction() public | オークションの終了時に資金をAutonomousConverterに送信します。 | 869 | 870 | Metronome自動交換コントラクト 871 | --------------------------------------- 872 | 873 | ### 自動交換コントラクトのAPI 874 | 875 | 876 | 877 | 878 | 879 | 880 | 881 | 882 | 883 | 884 | 885 | 886 | 887 | 888 | 889 | 890 | 891 | 892 | 893 | 894 | 895 | 896 | 897 | 900 | 901 | 902 | 903 | 906 | 907 | 908 | 909 | 911 | 912 | 913 | 914 | 916 | 917 | 918 | 919 | 920 | 921 | 922 | 923 | 924 | 925 | 926 | 927 | 928 | 929 | 930 |
function () public payableAutonomousConverterに入ってくる資金を処理します。
function init(address _reserveToken, address _smartToken, address _proceeds, address _auctions) public payable初期展開中に呼び出されます。これはオーナーのみの関数です。
function getMetBalance() public view returns (uint)コントラクトのMETの残高を示します。
function getEthBalance() public view returns (uint)コントラクトのETHの残高を示します。
function convertEthToMet(uint _mintReturn) public payable returns (uint returnedMet)ETHをMETに変換します。返されたMET 898 | がminReturn未満の場合は捨てられます。 899 | METの金額を返します。
function convertMetToEth(uint _amount, uint _mintReturn) public returns (uint returnedEth)METをETHに変換します。返されたETH 904 | がminReturn未満の場合は捨てられます。ETHの金額を返します。転送を行うには、まずコーラーがACを承認する必要があります。 905 |
function getMetForEthResult(uint _depositAmount) public view returns (uint256)ETHで指定された_depositAmountに対してユーザーが 910 | どれだけのMETを取得するかを返します。
function getEthForMetResult(uint _depositAmount) public view returns (uint256)METで指定された_depositAmountに対してユーザーが 915 | どれだけのETHを取得するかを返します。
event LogFundsIn(address indexed from, uint value)AutonomousConvertが資金を受け取ったときに送信されます。
event ConvertEthToMet(address indexed from, uint eth, uint met)ETHからMETへの変換が行われたときに送信されます。
event ConvertMetToEth(address indexed from, uint eth, uint met)METからETHへの変換が行われたときに送信されます。
931 | 932 | TokenLocker 933 | ----------- 934 | 935 | ### TokenLockerのAPI 936 | 937 | | event Withdrawn(address indexed who, uint amount) | すべての引き出しに対して送信されます。 | 938 | | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | 939 | | event Deposited(address indexed who, uint amount) | すべての入金で発信されます。 | 940 | | function lockTokenLocker() public onlyAuction | tokenLockerをロックします。この関数を呼び出すと、tokenLockerのpostLockフェーズを招きます。それ以上の入金ができなくなります。このフェーズではトークンの引き出しは許可されています。これはオークションのみの関数です。 | 941 | | function deposit (address beneficiary, uint amount) public onlyAuction preLock | 資金をロッカーに入金します。資金を入金することは、preLockフェーズでのみ許可されています。 | 942 | | function withdraw() public onlyOwner postLock | 資金を引き出すことは、postLockフェーズでのみ許可されています。これはオーナーのみの関数です。 | 943 | 944 | TokenPorter 945 | ----------- 946 | 947 | ### TokenPorterのAPI 948 | 949 | | event ExportReceiptLog(bytes8 destinationChain, address indexed destinationMetronomeAddr, address indexed destinationRecipientAddr, uint amountToBurn, bytes extraData, uint currentTick, uint indexed burnSequence, bytes32 currentBurnHash, bytes32 prevBurnHash, uint dailyMintable, uint\[\] supplyOnAllChains, uint genesisTime) | エクスポートリクエスト中に発信されます。 | 950 | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | 951 | | function addDestinationChain(bytes8 \_chainName, address \_contractAddress) public onlyOwner returns (bool) | Metronomeのエクスポートの承認済みのチェーンとしてチェーンを追加します これはオーナーのみの関数です。 | 952 | | function removeDestinationChain(bytes8 \_chainName) public onlyOwner returns (bool) | Metronomeのエクスポートの承認済みのチェーンからチェーンを削除します。これはオーナーのみの関数です。 | 953 | | function claimReceivables(address\[\] recipients) public returns (uint) | この関数は、Metronomeのインポートを実行する宛先コントラクトによって呼び出され、宛先コントラクトでMetronomeの造幣を記録します。 | 954 | | function export(bytes8 \_destChain, address \_destMetronomeAddr, address \_destRecipAddr, uint \_amount, bytes \_extraData) public returns (bool) | 別のチェーンにインポートするユーザーアカウントをエクスポートします。 | 955 | 956 | 957 | 958 | コントラクトの用語集 959 | ========================== 960 | 961 | - **自動交換コントラクト** MTHをETHに、またはETHをMETに交換することができるスマートコントラクト。 962 | 963 | - **自動収益プロバイダー** Metronomeの収益コントラクトと自動交換コントラクト。 964 | 965 | - **コンスタント** DECIMALSのように数個の共通のコントラクトを保持する。 966 | 967 | - **日次供給ロット** 日ごとに新しく造幣したMETをエコシステムに追加する競り下げ式オークション。 968 | 969 | - **EVM** イーサリアム仮想マシンの標準。[^44] 970 | 971 | - **Fixed\_Math** 加算、除算、乗法、除法、2乗、平方根を含め、固定小数点の演算を実装します。オーバーフロープロテクションを含みます。 バイナリ関数では、両方の入力が同じ数の少数位を持つものと仮定します。 972 | 973 | - **数式** 固定演算機能を使用して、バンコール様式の数式を実装します。数式はステートレスで、すべての変数はパラメーターとして渡されます。 974 | 975 | - **Metronome** 主なオークションコントラクト。 976 | 977 | - **移行** Truffleの移行機能。 978 | 979 | - **ReserveToken** METを実装する。自動交換コントラクトにトークンを移動する権利を与える（取引イベントにおいて）。 980 | 981 | - **収益コントラクト** MetronomeからETHを受け取り、残高の0.25%を24時間おきに自動交換コントラクトに転送する。 982 | 983 | - **スマートトークン** 自動交換コントラクト経由でMETとETH間で変換する際に仲介として動作する、自動交換コントラクトによって発行されるトークン。このプロセスは自動化されており、ユーザーには公開されていません。 984 | 985 | - **トークン** 購入者によって購入されるMETトークン。 986 | 987 | 付録A 988 | ========== 989 | 990 | 了承事項と免責事項 991 | 992 | METRONOMEトークンを購入、所有、および/または使用することにより、あなたは明示的に次のリスクを承認し、引き受けることになります。 993 | 994 | 1. **[Purchaser Acknowledgments]**。Metronomeトークン（「MET」）の購入者（「購入者」または「あなた」）として、あなたは以下を承認するものとします。 995 | 996 | a. MET[not]は、セキュリティまたは 997 | その他の投資プロダクトの形式で構成されているか、販売されています。METは、1933年の証券取引法の下で、改正された、 998 | または州の証券行為の下で、 999 | またはその他の管轄区域における同様の法律の下においても、 1000 | 米国証券取引所には 1001 | 登録されておらず、それらの法律に基づく 1002 | 免責条項が適用されます。したがって、オーナーズマニュアルに提示されている情報は 1003 | いずれも投資の決定の基準を 1004 | 形成することを意図としておらず、 1005 | 特定の推薦も意味していません。METの使用、販売またはその他の処分は、 1006 | オーナーズマニュアルに記述されているように 1007 | 制限されています。METを取得することにより、購入者は、 1008 | オーナーズマニュアルのすべての必要条件およびアメリカ連邦法、州法、地域法を含む、 1009 | いかなる管轄区域によって発布されたいかなる法律にも 1010 | 準拠するものとします。METの作成者は、次の事項から直接的または間接的に生じる、 1011 | 直接または結果としてのいかなる種類の損失または損害に対しても、 1012 | 一切の責任を明示的に否認します。 1013 | （i）オーナーズマニュアルまたはその他のドキュメンテーションに 1014 | 含まれている一切の情報へ頼ること（ii）そのような情報のエラー、脱落部分、または不正確な情報 1015 | または（iii）そのような情報を基にした 1016 | 一切の行動。 1017 | 1018 | b. このドキュメントはシンガポールの通貨当局には 1019 | 投資資料としては登録されておらず、登録する予定もありません。これは、証券および先物取引法 1020 | （Cap. 289 of Singapore）（「**SFA**」）で定義されている 1021 | 投資資料ではありません。 従って、投資資料の内容に関連する 1022 | SFAの下での法定責任は 1023 | 適用されません。 1024 | 1025 | c. あなたは、METまたはMetronomeを使用して、 1026 | 先物取引のコントラクト、スワップ、 1027 | または再販商品のトランザクションを作成することを含め、 1028 | 米国商品先物取引委員会によって規制されているプロダクトを作成しないものとします。さらに、あなたは、METの購入はいかなる形式の 1029 | オプションまたはスワップトランザクションを 1030 | 意図としたものではなく、そのようなものとして販売しないことを認めるものとします。 1031 | 1032 | d. METを理解し、METを使用、購入および/または破棄することの 1033 | リスクと影響を認識するために、あなたは暗号トークン、 1034 | トークンのストレージメカニズム（トークンウォレットなど）、 1035 | およびブロックチェーンテクノロジーに関連する技術上およびビジネス上の 1036 | 事項を理解するものとします。 1037 | 1038 | e. あなたは、METについての十分な情報を入手して、 1039 | 情報に基づいてMETを購入する決定をし、METを購入する決定を下す際に 1040 | オーナーズマニュアルに提供されている以外のいかなる情報 1041 | にも依存していないものとします。 1042 | 1043 | f. あなたは、オーナーズマニュアルで意図されているようにMETを使用する権利のみを 1044 | METによって与えられていることを理解するものとします。METでは、いかなるエンティティの所有権、配布、買い戻し、 1045 | 現金化、独占所有権（知的財産を含む）、 1046 | または金融または法律上の権利を含め、 1047 | ただしこれに限定されるものではなく、 1048 | それ以外の権利をいかなる形式でも与えていません。 1049 | 1050 | g. あなたは、オーナーズマニュアルで意図されているように 1051 | METを使用する目的でのみMETを購入し、METに関連付けられている商業上のリスクについて 1052 | 認識しているものとします。あなたは、いかなる投資、投機、または金融目的を含め、 1053 | ただしこれに限定されるものではなく、それ以外の目的ではMETを 1054 | 購入しないものとします。 1055 | 1056 | h. あなたのMETの購入は、 1057 | あなたの管轄区域で該当する法律および規制に準拠します。これには、次が含まれますが、 1058 | これに限定されるものではありません。（i）METの購入に対する法的能力といかなる 1059 | 必要条件または制限（ii）そのような購入に対して適用される 1060 | いかなる外国為替または規制上の制（iii）取得すべき 1061 | いかなる政府またはその他の同意。 1062 | 1063 | i. あなたは、METの購入または使用から生じる適用税金に対して 1064 | 単独で責任を負うものとします。 1065 | 1066 | j. あなたがあるエンティティの代わりにMETを購入する場合は、 1067 | あなたにそのようなエンティティの代わりにこれらの了承事項と免責事項に同意する 1068 | 権限があるものとします。 1069 | 1070 | k. あなたは次に該当しません。(i) METの配布を受け入れることが 1071 | 適用される法律、法令、規制、条約、 1072 | または行政行為によって禁止されている 1073 | 地域の市民または住民（ii）国連、EU、米国またはその他の主権国の制裁または禁輸の対象 1074 | となっている地域の市民または住民、 1075 | または所在する（iii）米国商務省が拒否した人物または団体リスト、 1076 | 米国財務省の特別に指定された国民またはブロックされた人物リスト、 1077 | または米国国務省のデバレド・アフィリエイトプログラムリスト、 1078 | またはいかなるその他の該当する主権国の同様な制限された 1079 | 人物の規制やリスト、 1080 | あるいは上記のいずれかに対する後継者の規制または制限で特定される個人、 1081 | またはそのようなエンティティに雇われているか 1082 | 関連付けられている個人。 あなたは、上記の了承事項がもはや正確でないように、 1083 | 居住国またはその他の環境が変わった場合には、 1084 | METの使用を即座に停止することに 1085 | 同意するものとします。 1086 | 1087 | l. METの価値は、暗号通貨として受け入れられるかどうか、 1088 | また、商品やサービスの支払いに使用される範囲 1089 | によって異なります。不適切な需要は、商品やサービスの支払いに 1090 | METを活用することを困難にし、結果的にMETの価値を低下させる 1091 | 可能性があります。 同様に、METが汎用的に採用されていない場合、 1092 | 価値が低下する可能性があります。さらに、短期的には、METの価値を 1093 | 大幅に低下させる可能性のある、暗号通貨とトークン販売の監視に 1094 | 関連する実質的な規制リスクが 1095 | 残っています。 1096 | 1097 | m. METの価値は、商品やサービスの支払い用の暗号通貨としての 1098 | METの使用が普及することからくる価値に依存する 1099 | はずです。 1100 | 1101 | n. METの価格は、暗号通貨としての 1102 | METの一般的な供給と需要に影響を及ぼす競合と市場状況に応じて 1103 | 変動するはずです。 これらの状況は、特定の当事者またはMET保有者が 1104 | 制御できる範囲を越えています。 使用または交換されたときのMETの価値は、 1105 | 購入時の価格よりも低くなる 1106 | 可能性があります。 1107 | 1108 | o. 定期的な自動化された独立したベースでの新しいMETのリリースは、 1109 | Metronomeエコシステムおけるサービスの 1110 | 本質的価値の周囲で、METの価格を安定させることを 1111 | 目的としていますが、METのそのようなリリースが成功するという保証はありません。また、自分のアカウントでいかなる価格でもMETを販売することが 1112 | できます。 1113 | 1114 | p. METの販売により、いかなる点においても、 1115 | Metronomeの作者が他のプロジェクトに参加したり、他のネットワークを運営したり、 1116 | METと競合する他のトークンを発行することから制限されることはありません。 1117 | 1118 | q. METに関しては、本来の価値を約束するものではなく、 1119 | 継続支払の催促もなく、METが特定の価値を保持するという保証も 1120 | 無いことを含め、将来の業績や価値についての 1121 | 約束は一切ありません。 1122 | 1123 | r. Metronomeの作者が独自のMETの販売からの収益をどのように使用するかに 1124 | 関する条件はありません。 1125 | 1126 | 2. **[特定リスクの了承]**。METに関しては以下のリスクが存在し、 1127 | これらのリスクを明示的に前提にしていることに 1128 | 同意することになります。 1129 | 1130 | s. ***METの自動性***。METは自主的に運営されており、 1131 | METの操作に影響を与えたり管理したりすることは 1132 | できません。METの自動性は、MTNのローンチ時またはあなたの購入時には 1133 | 予見できないリスクを含む、将来リスクを引き起こす可能性が 1134 | あります。 1135 | 1136 | t. ***秘密鍵の紛失、預託者のエラーまたは購入者のエラーによる 1137 | METへのアクセスを失うリスク。***デジタルウォレットまたはボールトに 1138 | 保管されているMETを制御して廃棄するには、 1139 | 秘密鍵または秘密鍵の組み合わせが必要です。したがって、METを格納するデジタルウォレットまたは 1140 | ボールトに関連付けられている必須の秘密鍵の損失は、そのようなMETの損失を 1141 | もたらします。さらに、そのような秘密鍵へのアクセスを獲得した第三者は、 1142 | あなたが使用しているホストされたウォレットサービス 1143 | のログイン資格情報へアクセスすることを含め、 1144 | METを誤用する可能性があります。METを受け取って格納するために選択したデジタルウォレット 1145 | またはボールトによって引き起こされた、 1146 | またはそれに関連して引き起こされたエラーや機能不全により、 1147 | そのようなデジタルウォレットまたはボールを適切に管理したり使用したりすることを 1148 | 怠ったことを含め、METを失う可能性があります。 1149 | さらに、例えば、間違った住所を入力した場合など、 1150 | METを購入して受け取る手続きを正確に守らないと、 1151 | METを失う可能性があります。 1152 | 1153 | u. ***ブロックチェーンプロトコルに関連するリスク。***METが運営しているブロックチェーンの 1154 | プロトコルの機能不全、故障、 1155 | または放棄は、METに重大な悪影響を 1156 | 及ぼす可能性があります。さらに、暗号技術の進歩や技術の進歩により、 1157 | ブロックチェーンプロトコルの基盤となる暗号のコンセンサスメカニズムが 1158 | 効果的でなくなることによって、METにリスクをもたらす可能性が 1159 | あります。 1160 | 1161 | v. ***マイニング攻撃のリスク。***METは、二重支払い攻撃、51%攻撃、 1162 | トランザクションの選択的な遅延または検閲、 1163 | およびセルフィッシュマイニング攻撃を含むが、 1164 | これに限定されない攻撃によって、ブロックチェーン上のMETトランザクションの検証中に、 1165 | マイナーによる攻撃を受けやすいと言えます。 成功した攻撃は、METに関連するトランザクションの正確な実行および 1166 | 記録を含むが、これに限定されずに、METにリスクを与える 1167 | 可能性があります。 1168 | 1169 | w. ***ハッキングの危険性とセキュリティの弱点。***ハッカーやその他悪意のあるグループや組織は、 1170 | マルウェアの攻撃、サービス拒否攻撃、コンセンサスベースの攻撃、 1171 | サイビル攻撃、スマッフィングやなりすましを含むが、 1172 | これらに限定されないさまざまな方法でMETに干渉しようとする 1173 | 可能性があります。 さらに、METはオープンソースソフトウェアに基づいているため、 1174 | METに悪影響を与える第三者が故意にまたは意図せずに、 1175 | METの新しい実装のコアインフラストラクチャに、 1176 | 弱点を導入するリスクがあり、これがMETに悪影響を与える 1177 | 可能性があります。ハッカーやその他の悪意のあるグループや組織は、 1178 | METを受け取り格納するために使用されるウォレット、ボールト、またはその他 1179 | のストレージメカニズムの秘密鍵またはその他のアクセス資格情報へのアクセス権を取得しようと 1180 | 試みる可能性があります。 1181 | 1182 | x. ***METの市場に関連するリスク。***METのセカンダリトレーディングが第三者の交換によって 1183 | 促進される場合、そのような交換は比較的新しいものであり、 1184 | 規制によってほとんどまたは全く監視されていないため、 1185 | 詐欺や操りの影響を受けやすく 1186 | なります。さらに、第三者が外部交換価値 1187 | （例えば、デジタル通貨または現金通貨建て）をMET 1188 | のせいにする場合、そのような価値は極めて変動しやすく、 1189 | ゼロになる可能性があります。 1190 | 1191 | y. ***無保険損失のリスク。*** 特定の銀行口座やその他の金融機関の口座とは 1192 | 異なり、METは保険対象外 1193 | です。このように、使用価値の喪失または損失の場合には、援助手段を 1194 | 提供する公的保険会社または民間保険は存在しません。 1195 | 1196 | z. ***不確実な規制および強制措置に 1197 | 関連するリスク。*** 多くの管轄区域では、METと分散型元帳テクノロジーの 1198 | 規制状況が不明確または不安定です。 規制当局がそのようなテクノロジーに関して 1199 | どのように既存の規制を適用するか、または適用するかどうか、 1200 | またMETを含め、その使用法に賛同するかどうかを予測することは 1201 | 難しいと言えます。 立法府や規制当局が、 1202 | METを含む、分散型台帳テクノロジーと 1203 | その使用法に影響を与える法律や規制への変更を 1204 | どのように実施するか、または実施するかどうかを予測することは、 1205 | 同様に難しいと言えます。説明の目的でのみですが、 1206 | 例えば、METの購入、販売、配送が違法行為を構成していること、 1207 | またはMETがそれらの証書またはその購入、販売および配送に 1208 | 関与する当事者の一部または全員の登録または 1209 | ライセンス供与を必要とする規制された手段であることの決定を通じて、 1210 | 規制上の行為は様々な形でMETに悪影響を与える 1211 | 可能性があります。 1212 | 1213 | a. ***課税から生じるリスク。*** METの税金特性付けは不確実で、 1214 | 税金の源泉徴収、所得税、および税金申告を含め、 1215 | 税金上で不利な結果を招く可能性が 1216 | あります。METと関連して独自の税金アドバイザーにご相談する 1217 | 必要があります。 1218 | 1219 | b. ***テクノロジーのリスク。*** METは、使用において完全に証明されていない 1220 | 新テクノロジーにおける新しい機能を代表しています。テクノロジーが成熟するにつれて、 1221 | 新しい機能がMETの有益性やMTNを使用または販売する能力を 1222 | 極端に変える可能性があります。 1223 | 1224 | c. ***予期しないリスク。*** この付録に含まれているリスクのほかに、 1225 | 予期しないリスクを含め、METの購入、所有、 1226 | および使用に関連するリスクはその他にも 1227 | 存在します。そのようなリスクは、この付録に記述されている 1228 | リスクの予期しないバリエーションまたは組み合わせとして 1229 | さらに具体化することができます。 1230 | 1231 | 1232 | 1233 | 1. **[免責事項]**。それぞれのMETは、商品性、特定の目的への適合性、タイトルまたは非侵害性の黙示の保証を含め、いかなる種類の保証もなく、「現状有姿」で提供されています。 1234 | 1235 | [^1]: 1236 | 1237 | [^2]: 1238 | 1239 | [^3]: 1240 | 1241 | [^4]: 1242 | 1243 | [^5]: 1244 | 1245 | [^6]: 1246 | 1247 | [^7]: Tsiang, S.C., Journal of Money, Credit and Banking, I(1969), pp. 1248 | 266--80 \"A Critical Note on the Optimum Supply of Money\" 1249 | 1250 | [^8]: 1251 | 1252 | [^9]: 1253 | 1254 | [^10]: 1255 | 1256 | [^11]: 1257 | 1258 | [^12]: 1259 | 1260 | [^13]: 1261 | 1262 | [^14]: 1263 | 1264 | [^15]: ソース: coinmarketcap, coinbase, blockchain.info, FederalReserve Bank of St Louis 1265 | 1266 | [^16]: 1267 | [^17]: Mishra, Debasis, and David C. Parkes. "Multi-Item Vickrey-Dutch 1268 | Auctions." Games and Economic Behavior, vol. 66, no. 1, 2009, pp. 1269 | 326--347., doi:10.1016/j.geb.2008.04.007. 1270 | 1271 | [^18]: 1272 | 1273 | [^19]: ソース: coinmarketcap.com, coinbase, blockchain.info 1274 | 1275 | [^20]: 1276 | 1277 | [^21]: 1278 | 1279 | [^22]: 1280 | 1281 | [^23]: 1282 | 1283 | [^24]: ソース: coinmarketcap.com, coinbase, blockchain.info 1284 | 1285 | [^25]: 1286 | 1287 | [^26]: 1288 | 1289 | [^27]: 1290 | 1291 | [^28]: 1292 | 1293 | [^29]: 1294 | 1295 | [^30]: 1296 | 1297 | [^31]: 1298 | 1299 | [^32]: 1300 | 1301 | [^33]: 1302 | 1303 | [^34]: 1304 | 1305 | [^35]: 1306 | 1307 | [^36]: 1308 | 1309 | [^37]: 1310 | 1311 | [^38]: 1312 | 1313 | [^39]: 1314 | 1315 | [^40]: 1316 | 1317 | [^41]: 1318 | 1319 | [^42]: 1320 | 1321 | [^43]: 1322 | 1323 | [^44]: 1324 | 1325 | -------------------------------------------------------------------------------- /owners_manual/owners_manual_ko.md: -------------------------------------------------------------------------------- 1 | ![메트로놈](img/logo.png) 2 | 3 | 버전 0.986(마지막 업데이트 2018.05.30) 4 | 5 | **참고:** 6 | 7 | \(1) 이 소유자 설명서 초안은 아직 진행 중인 작업으로서 새로운 유형의 가상화폐인 메트로놈의 설계와 구조를 설명합니다. 메트로놈과 그 기반 기술은 아직 개발 중이며 이 소유자 설명서는 전체 개발 사이클의 변경 사항을 반영할 수 있도록 이러한 프로세스가 진행되는 동안 계속 업데이트될 예정입니다. 자료의 정확성을 보장하기 위한 모든 조치를 수행하고 있으나, 메트로놈 개발자 및 해당 파트너는 이 소유자 설명서에 실린 자료의 정확성 또는 완벽성을 보증하지 않습니다. 8 | 9 | \(2) 메트로놈의 잠재적 구매자 및 메트로놈 상태계의 참가자는 부록 \[A\]의 승인 및 부인을 포함하여 이 소유자 설명서의 내용을 읽어야 하며 구매 전 모든 위험을 신중하게 고려해야 합니다. 10 | 11 | **소유자 설명서 라이선스** 12 | 13 | © 2018 Autonomous Software. All rights not expressly granted by Licensor 14 | are hereby reserved. 15 | 16 | AUTONOMOUS SOFTWARE("라이선스 제공자")는 이 메트로놈 소유자 설명서("소유자 설명서") 및 일반 버전(아래에 정의됨)에 대한 독점적 소유권, 모든 권한, 소유권, 이권, 모든 저작권 및 기타 지적 재산권을 소유하고 유지합니다. 이 소유자 설명서 및 일반 버전은 본 문서에서 "작업물"로 총칭합니다. 17 | 18 | "메트로놈," "MET", 메트로놈 로고는(총칭 "메트로놈 상표") 라이선스 제공자의 상표이며 라이선스 제공자의 명시적 서면 승인이 있는 경우에만 사용할 수 있습니다. 메트로놈 상표 또는 혼동될 만큼 유사한 상표를 기타 제품 또는 서비스에 사용하거나 그와 관련하여 사용하거나 또는 광고 또는 소프트웨어나 하드웨어에 사용하는 것 포함하여 시장에 혼란을 줄 수 있는 기타 방식으로 사용할 수 없습니다. 19 | 20 | 1. **라이선스 부여 및 제한.** 이 라이선스의 약관에 따라 21 | 라이선스 제공자는 귀하에게 본 소유자 설명서 전체를(부분 발췌 불가) 22 | 수정 없이 복사, 전시, 배포할 수 있고 일반 버전(아래에 정의됨)의 23 | 파생 작업물을 수정하거나 만들고 24 | 이러한 작업물을 복사, 전시, 25 | 배포할 수 있는 전 세계에서 통용되는 로열티 없는, 비독점적인, 영구 라이선스를 부여합니다. 26 | 이는 전술한 사항이 귀하 또는 귀하의 27 | 작업물이나 가상화폐, 스마트 계약 28 | 또는 그에 설명된 기술이 어떠한 방식으로든 라이선스 제공자 또는 해당 계열사와 관계가 29 | 있거나 보증을 받는다는 것을 의미하지 않는 경우에 한합니다. 30 | 위의 권한은 현재 알려져 있거나 현재 이후에 고안된 모든 31 | 매체와 형식으로 행사할 수 있습니다. 위의 권한에는 기타 32 | 매체와 형식으로 권한을 행사하는 데 기술적으로 필요한 경우 수정할 수 있는 33 | 권한이 포함됩니다. 작업물을 배포하거나 공개적으로 시연할 34 | 때마다, 라이선스 제공자는 본 라이선스에 의거하여 귀하에게 35 | 부여된 것과 동일한 약관을 토대로 수급자에게 작업물에 대한 36 | 라이선스를 부여합니다. "일반 버전"이란 라이선스 제공자, 라이선스 37 | 제공자의 계열사 또는 메트로놈, MET이라는 단어 또는 모든 38 | 메트로놈 상표에 대한 언급이 포함되지 않은 버전의 39 | 소유자 설명서를 의미합니다. 40 | 41 | 2. **소유자 설명서에 대한 제안 수정 사항.** 본 소유자 설명서에 대한 42 | 제안 수정 사항을 제출할 경우, 귀하는 이에 따라 라이선스 제공자에게 43 | 이러한 제안 수정 사항에 대한 제한이 없는 모든 저작권을 부여하게 44 | 됩니다. 이러한 경우, 라이선스 제공자는 고유 재량에 따라 소유자 45 | 설명서에 이러한 제안 수정 사항(전체 또는 부분, 수정되거나 46 | 수정되지 않은 형태)을 포함하거나 포함하지 않도록 선택할 수 47 | 있습니다. 48 | 49 | 3. **진술 및 보증 고지 사항**. 본 소유자 설명서는 모든 종류의 명시적, 묵시적, 법적 보증 또는 소유권 보증, 상품성, 특정 목적에의 적합성, 비침해, 정확성 또는 오류의 존재 유무를 비롯하되 이에 국한되지 않고 그 밖의 진술이나 보증 없이 있는 그대로 제공됩니다. 일부 재판관할권에서는 묵시적 보증의 제외를 허용하지 않으므로, 이러한 제외가 귀하에게 적용되지 않을 수 있습니다. 50 | 51 | 4. **시행 가능성**. 본 라이선스의 조항이 유효하지 않거나 준거법에 의거하여 시행 불가능한 경우, 이는 본 라이선스의 나머지 약관의 유효성이나 시행 가능성에 영향을 미치지 않으며, 본 계약의 당사자들의 추가 조치가 없어도 이러한 조항을 유효하고 시행 가능하도록 만드는 데 필요한 최소한의 범위 내에서 이러한 조항이 개선되어야 합니다. 권리 포기 또는 승인 책임이 있는 당사자가 이러한 권리 포기 또는 승인에 서면으로 서명한 경우를 제외하고는 본 라이선스의 약관이나 조항에 대한 권리를 포기하는 것으로 간주되지 않으며 위반이 승인되지 않습니다. 52 | 53 | 5. **조약상의 권한**. 본 라이선스에 따라 부여된 권한, 그리고 본 라이선스에서 언급된 주제는 문학 및 예술 작품의 보호를 위한 베른 협약(1979년 9월 28일 개정본 기준), 1961년 로마 협약, 1996년 WIPO 저작권 조약, 1996년 WIPO 공연 및 음반 조약 및 세계 저작권 협약(1971년 7월 24일 개정본 기준)의 용어를 활용하여 초안이 작성되었습니다. 이러한 권리와 주제는 국가 준거법 내에 있는 조약 조항의 구현에 대한 해당 조항에 따라 라이선스 약관을 시행하고자 하는 관련 재판관할권 내에서 발효됩니다. 저작권 준거법에 따라 부여된 일반적인 권한에 본 라이선스에서 부여하지 않은 추가 권한이 포함될 경우, 이러한 추가 권한은 본 라이선스에 포함되는 것으로 간주됩니다. 본 라이선스는 준거법에 따른 모든 권한의 라이선스를 제한하기 위한 것이 아닙니다. 54 | 55 | 목차 56 | ================= 57 | 58 | **[목차](#table-of-contents)** 59 | 60 | **[표 및 그림 목록](#list-of-tables-and-figures)** 61 | 62 | **[동기](#motivations)** 63 | 64 | > [가상화폐를 한 차원 더 높은 수준으로 개선](#taking-cryptocurrency-to-the-next-level-literally) 65 | 66 | **[사업 요약 보고서](#executive-summary)** 67 | 68 | **[배경](#background)** 69 | 70 | > [블록체인 기술](#blockchain-technology) 71 | > 72 | > [가상화폐](#cryptocurrency) 73 | > 74 | > [내림 경매](#descending-price-auctions) 75 | 76 | **[메트로놈 소개](#introducing-metronome)** 77 | 78 | **[메트로놈 작동 원리](#how-metronome-works)** 79 | 80 | > [크로스 블록체인 호환성](#cross-blockchain-portability) 81 | > 82 | > [분산된 자발적 합의 > 관리](#distributed-voluntary-consensus-governance) 83 | 84 | **[가상화폐 시장 현황](#cryptocurrency-market-context-to-date) ** 85 | 86 | > [환경](#the-landscape) 87 | 88 | **[메트로놈 계약 및 기술적 측면](#metronome-contracts-and-technical-aspects)** 89 | 90 | **[메트로놈 수익금 및 자율환산계약](#metronome-proceeds-and-autonomous-converter-contracts)** 91 | 92 | **[토큰 공급량의 경제학](#token-supply-economics)** 93 | 94 | > [이론](#theory) 95 | > 96 | > [공급표](#supply-schedule) 97 | > 98 | > [메트로놈 코어](#metronome-core) 99 | > 100 | > [토큰 API](#token-api) 101 | > 102 | > [경매 API](#auction-api) 103 | > 104 | > [메트로놈 수익금 계약](#metronome-proceeds-contract) 105 | > 106 | > [수익금 계약 API](#proceeds-contract-api) 107 | > 108 | > [메트로놈 자율환산계약(Autonomous Converter Contract)](#metronome-autonomous-converter-contract) 109 | > 110 | > [자율환산계약(Autonomous Converter Contract) API](#autonomous-converter-contract-api) 111 | > 112 | > [TokenLocker](#tokenlocker) 113 | > 114 | > [TokenLocker API](#tokenlocker-api) 115 | > 116 | > [TokenPorter](#tokenporter) 117 | > 118 | > [TokenPorter API](#tokenporter-api) 119 | 120 | **[계약 약관 용어](#glossary-of-contract-terms) ** 121 | 122 | **[부록 A](#appendix-a) ** 123 | 124 | 표 및 그림 목록 125 | ========================== 126 | 127 | 그림 1: USD와 BTC의 본원통화 비교 11 128 | 129 | 그림 2: 메트로놈 계약 간의 흐름과 상호 작용 12 130 | 131 | 그림 3: 크로스 블록체인 호환성에 대한 설명 15 132 | 133 | 그림 4: 유명한 가상화폐의 조폐율 18 134 | 135 | 그림 5: 비트코인과 메트로놈의 조폐율 및 공급량 비교 19 136 | 137 | 그림 6: ZEC와 MET 개발자의 보유분 비교 20 138 | 139 | 표 1: 오늘날 가상화폐 간의 중요 140 | 특성 비교 21 141 | 142 | 그림 7: 자율환산계약(Autonomous Converter Contract) 작동 원리 22 143 | 144 | 표 2: 공급표 27 145 | 146 | 147 | 148 | 동기 149 | =========== 150 | 151 | 메트로놈의 개발 과정에서, 메트로놈 개발 팀은 이전 가상화폐로부터 얻은 교훈을 타산지석으로 삼고자 했으며 장기적인 통화 체계로 자리잡는 것이 유일한 목표인 가상화폐를 개발하고자 했습니다. 이를 염두에 둔 메트로놈 개발 팀은 다음과 같은 측면에서 새로운 기회를 포착했습니다. 152 | 153 | - 지속되는 기술을 경제적인 방식으로 개발 154 | 155 | - 분산형 금융 상품 부트스트랩핑 156 | 157 | - 토큰 분배에 대한 평등한 접근 보장 158 | 159 | - 자율적인 자치구조 계약 보장 160 | 161 | - 가상화폐를 한 차원 더 높은 수준으로 개선 162 | 163 | **지속되는 기술을 경제적인 방식으로 개발** 164 | 165 | 일부 가상화폐의 발행량은 제한되어 있거나 비트코인[^1],[^2] 및 라이트코인처럼[^3] 시간이 지나면 전혀 발행할 수 없으므로, 경제학자들은 가상화폐의 장기적인 수명에 대해 많은 의문을 제시하고 있습니다.[^4],[^5] 다른 가상화폐의 토큰 공급량은 특정 당사자에게 막대한 양의 공급량을 지급하는 사전 ICO 거래에서 사람의 손에 의해 서로 조절되므로, 이러한 당사자가 대다수의 토큰을 통제하는 결과로 이어집니다. 또 어떤 가상화폐는 사전 판매 또는 비공개 판매에서 특정 당사자에게 모두 매각되기 때문에 일반 대중에게 돌아가는 몫은 거의 없는 경우도 있습니다. 메트로놈은 지속적인 166 | 토큰 공급량 발행을 무제한으로 제공하는 일일 경매를 통해 이러한 문제를 해결하고자 합니다. 지속적인 토큰 공급량은 화페 발행이 없거나 없어지는 다른 가상화폐에 비해 지속 가능성을 제공하는 것을 이론화합니다.[^6],[^7] 메트로놈 개발 팀은 또한 이를 통해 MET 보유자가 메트로놈의 여러 가지 결제 기능을 사용하도록 장려할 것으로 167 | 예상합니다. 사실 상의 화폐로 메트로놈을 사용하게 되면 메트로놈의 견고성이 강화될 것입니다. 이와 더불어, 메트로놈 개발 팀은 지속적인 화폐 발행이 일정 기간에 구매된 잠재적인 불균형한 양을 희석하는 역할을 할 것이라 봅니다. 메트로놈 개발 팀은 메트로놈을 통해 오래 지속될 수 있는 기술을 개발하고 있다고 믿습니다. 지속성이 바로 메트로놈의 주요 목표입니다. 168 | 169 | **분산형 금융 상품 부트스트랩핑** 170 | 171 | 분산형 시스템을 자급력 있는 체계로 부트스트랩핑하는 것은 단순한 기술이 아닌 새로운 차원의 문제입니다. 메트로놈은 이 분야의 새로운 기원을 열고자 합니다. 메트로놈 경매의 모든 수익금은 두 가지 별도의 스마트 계약에 전송되며[^8] 이는 무엇보다도, 매도를 원하는 MET 보유자에게 유동성을 제공하도록 고안된 것입니다.[^9] 172 | 173 | 모든 경매 수익금을 메트로놈 생태계 내에서 보유하게 되므로, 메트로놈 개발 팀에서는 메트로놈이 양적 성장을 할 수 있을 것으로 예상합니다. 또한, 타사에서도 프로젝트와 상품을 위해 메트로놈의 모델을 연구하게 될 것으로 전망합니다. 174 | 175 | **토큰 분배에 대한 평등한 접근 보장** 176 | 177 | 가상화폐는 더욱 평등해져야 합니다. 불과 1%가 아닌 더 많은 사람들이 전 세계의 다음 가상화폐에 접근할 수 있어야 합니다. 가상화폐에 대한 접근성이 대중에게 널리 확산되면 전체 메트로놈 경제 대비 다량의 지분을 갖고 있는 이해관계자의 수를 줄일 수 있습니다. 178 | 179 | 내림 경매의 목표는 구매자가 생각하기에 공정한 가격으로 토큰을 분배하는 것입니다.[^10] 다른 ICO의 토큰 분배는 사람 손에 의해 계획되며, 대중이 접근하기도 전에 대부분 사전 판매 및 비공개 판매에서 완료되는 경우가 많습니다.[^11] 180 | 181 | 메트로놈은 ICO 및 일일 공급량 둘 다에 내림 경매를 적용하여 대중이 모든 경매 기회에 접근할 수 있도록 합니다.[^12] 사전 판매, 화이트리스트 또는 보너스 같은 것은 없습니다. 메트로놈 경매에 참여하는 모든 사람은 다른 모두와 똑같은 규칙 내에서 메트로놈을 운용해야 합니다. 이러한 공개 경매에서는 그 누구도 예외가 적용되거나 특혜를 받을 수 없습니다.[^13] 182 | 183 | 메트로놈 개발 팀은 수량이 불균형한 MET에 접근하게 될 경우 확인된 시장 가격보다 비싸게 구매해야 할 가능성이 있으므로, 이러한 방식으로 ICO를 시행하면 이 영역에서 고래 투자자 및 여타 대규모 투자자가 MET 공급량을 독점하는 것을 방지할 수 있다고 봅니다. 그리고 구매자 커뮤니티 간에 더욱 공정한 분배가 가능해질 것입니다. 메트로놈은 단기간에 치고 빠지는 투기 세력을 위한 것이 아니며, ICO의 모든 요소는 MET에 대한 더욱 공정한 접근성과 184 | 분배를 제공하기 위한 것입니다. 185 | 186 | **자율적인 자치구조 계약** 187 | 188 | 사람은 실수를 할 수 있는 존재입니다. 소프트웨어와 수학의 예측성은 수십 년간 강화되었으며 미래에는 더욱 발전할 것입니다. 알고리즘은 정치와 무관하게 작동하며, 사람의 재량에 따라 과도한 인플레이션을 조장하거나 통화를 조작하지 않습니다. 자율적인 자치구조[^14] 계약을 도입하면 사람의 재량으로 사람이 가상화폐의 가치에 영향을 미칠 수 있는 여지가 없어집니다. 이러한 목표를 위해 메트로놈 스마트 계약의 소유권 기능은 차단될 예정이며, 향후 출시되면 아무도 이에 대한 소유권을 가질 수 없습니다. 메트로놈은 완전히 자율적으로 운영됩니다. 189 | 190 | 메트로놈은 스스로 조정되고 관리되도록 개발되었습니다. 따라서 메트로놈의 계약은 완전히 자율적이며, 개발자의 개입 없이도 예측 가능한 방식으로 작동할 것으로 전망합니다. 191 | 192 | 가상화폐를 한 차원 더 높은 수준으로 개선 193 | ---------------------------------------------------- 194 | 195 | 모든 다른 가상화폐는 하나의 블록체인 네트워크에 묶여 있습니다. LTC는 라이트코인 블록체인에서만 기록되고, BTC는 비트코인 블록체인에서만 기록됩니다. 한 가지 방식에만 종속될 경우 관리 불일치, 공급량 불확실성 등의 여러 위험 요소가 나타납니다. 시장에서는 크로스 블록체인의 필요성은 커녕, 이 기술이 가능하다는 사실조차 잘 모르고 있습니다. 196 | 197 | 메트로놈은 하나의 블록체인에 영구적으로 종속되지 않는 최초의 가상화폐입니다. 또한, 메트로놈은 하나의 블록체인과 영구 계약을 맺지 않고도 여러 최고의 블록체인 네트워크에 의해 보장될 수 있는 가능성을 가진 최초의 가상화폐입니다. 이는 혁신적인 가상화폐 분야에서도 완전히 새로운 개념입니다. 198 | 199 | 200 | 201 | 사업 요약 보고서 202 | ================= 203 | 204 | 메트로놈("메트로놈" 또는 "MET")은 제도권 수준의 지속성을 보장하도록 개발된 새로운 가상화폐입니다. 메트로놈은 비트코인 및 이더리움 같은 다른 가상화폐에서 얻은 교훈을 토대로 하며 향후 100년 이상 사용할 수 있도록 고안되었습니다. 205 | 206 | 메트로놈은 대중에게 평등한 접근 기회를 제공하는 방식으로 출시될 예정입니다. 출시 후 메트로놈은 설립자에게 특권을 부여하지 않으며 예측 가능성과 신뢰성이 높은 토큰 공급량이 제공됩니다. 207 | 208 | 메트로놈 토큰 공급량: 209 | 210 | - 최초 MET 10,000,000개 공급량 211 | 212 | - 공개 내림 경매를 통해 8,000,000개 분배(아래에 자세히 설명) 213 | 214 | - 설립자 보유율로 설립자에게 2,000,000개 분배(20%) 215 | 216 | - 특수 TokenLocker 계약에 대해 발행됨(API 섹션 참조) 217 | 218 | - ICO 종료 시 개발자가 25% 사용 가능 219 | 220 | - 나머지 75%는 12분기에 걸쳐 12번씩 균등한 양으로 제공 가능 221 | 222 | - 메트로놈 개발자만이 TokenLocker 계약에서 인출할 수 있으며, 상기 지정된 시간에만 가능 223 | 224 | - 일일 신규 MET 발행량 225 | 226 | - 공개 내림 경매를 통해 일일 MET 발행량 분배 227 | 228 | - 일일 발행량 - (i) 하루 2,880개의 MET 또는 (ii) 연간 남은 MET 공급량의 2.0000%(연율)에 해당하는 수량 229 | 230 | 메트로놈의 세 가지 핵심 설계 원칙은 자치구조, 신뢰성, 호환성입니다. 이러한 원칙은 메트로놈을 독보적이고 견고하게 만들어주는 요소입니다. 231 | 232 | - **자치구조** 233 | 234 | - 출시 후 설립자의 과도한 영향력 배제 -- 스마트 계약에 의해 자율적으로 관리됨 235 | 236 | - 개인이나 커뮤니티 간 불일치, 이견 또는 오해를 초래할 염려 차단 237 | 238 | - 대중이 모든 판매 기회에 접근할 수 있도록 지원 239 | 240 | - 100% 체인상에서 분산되고 감사 가능한 거래 241 | 242 | - 내림 경매를 통한 가격 책정 243 | 244 | - **신뢰성** 245 | 246 | - 예측 가능한 토큰 공급량 247 | 248 | - 무제한으로 일일 발행되는 새로운 MET - (i) 하루 2,880개의 MET 또는 (ii) 연간 MET 공급량의 2.0000%(연율) 중 더 큰 수량 249 | 250 | - 안정적이고 예측 가능한 새로운 무제한 토큰 공급량 발행 방식 251 | 252 | - 예측 가능한 가격 책정을 목적으로 설계됨 253 | 254 | - **호환성** 255 | 256 | - 크로스 블록체인 호환성을 통해 다른 계약 또는 다른 블록체인에서 증명 가능한 내보내기 및 가져오기 지원 257 | 258 | - 관리 문제와 불안정성으로부터 가상화폐에 추가 보호 장치 제공 259 | 260 | - 커뮤니티에서 새로운 체인 내보내기 및 가져오기 기능 개발 261 | 262 | - 원장 기술 플랫폼의 발전에 대비하여 향후 블록체인에 대한 마이그레이션 경로 구현 263 | 264 | - **추가 기능** 265 | 266 | - 15~30초 내에 최초 결제 완료 가능 -- 결제 시간은 기반 블록체인에 따라 다름 267 | 268 | - 일괄 결제 - 한 번의 작업으로 복수의 결제를 일괄 전송 269 | 270 | - 구독 - 사용자 간에 반복 결제 허용 271 | 272 | - 추가적인 맞춤 기능으로 ERC20 호환 273 | 274 | 본 문서에서는 세계 최초의 자치구조 크로스 블록체인 가상화폐이자 위의 조건을 유일하게 충족하는 새로운 가상화폐로서 메트로놈을 제안합니다. 앞으로 가상화폐 및 다른 토큰 커뮤니티에서 자체적으로 메트로놈을 사용하기 위한 방법을 고안할 것으로 예측됩니다. 275 | 276 | 자치구조를 실현하고 개선하기 위해 메트로놈 개발 팀은 ICO 이후 메트로놈 토큰에 대한 특권 지분을 보유하지 않습니다. 메트로놈은 ICO 및 일일 공급량 둘 다에 내림 경매를 사용하여 구매자가 공정하다고 생각하는 가격으로 구매할 수 있는 기회를 제공합니다. 277 | 278 | 279 | 배경 280 | ========== 281 | 282 | 블록체인 기술 283 | --------------------- 284 | 285 | 블록체인은 암호로 보호되는 새로운 유형의 기록 보관 기술로, 금융 분야에 매우 지대한 영향을 미칩니다. 이는 전체 생태계 내의 모든 단위에 적용되는 분산 원장 회계입니다. 전체 네트워크에 걸쳐 공개적이고 완전한 원장을 보유하려면 원장이 서로 동기화되고 동의되어야 합니다. 이를 노드라고 합니다. 노드는 블록체인 단위의 "이중 사용"을 방지하며 네트워크에서 블록 내 거래를 검증하는 역할도 합니다. 286 | 287 | 블록에는 거래 데이터, 이전 블록의 해시, 목표 해시, Nonce라고 하는 숫자가 패키지됩니다. 노드가 이러한 블록을 검증하면 채굴자는 블록에 있는 모든 데이터의 해시가 목표 해시를 충족하도록 하는 Nonce를 찾아서 검증된 블록을 블록체인에 기록합니다. 채굴자에게는 이러한 작업과 연산 기능에 대한 보상으로, 새로 발행된 가상화폐 단위가 지급됩니다. 288 | 289 | 블록체인의 "체인"은 채굴자가 분산 공개 원장에 기록하는 끊임없이 이어진 채굴된 블록 라인을 말합니다. 채굴자가 새로운 블록을 성공적으로 발굴하려면 이전 블록의 데이터를 통합해야 하므로, 이는 가상화폐의 맨 처음에 대해 추적 가능한 내역을 만듭니다. 290 | 291 | 가상화폐 292 | -------------- 293 | 294 | 가상화폐는 암호화 기술을 사용하여 시장에 추가로 유입되는 새로운 통화 공급량을 조절하는 디지털 통화입니다. 새로 발행되는 가상화폐는 위에 설명한 채굴 과정에서 블록 발굴에 성공했을 때 보상으로 지급되는 경우가 많습니다. 암호화는 소유자가 변경되는 자금의 유효성을 검증하는 역할도 합니다. 그리고 거래 사용자가 보유한 프라이빗 키를 통해서만 지갑 간의 자금 이체가 인증됩니다. 이러한 거래는 블록체인에서 표시되며(위 내용 참조) 암호화 키의 사용은 해당 사용자가 자금을 송금할 의도가 있고 거래하기에 충분한 자금을 보유하고 있음을 보증하므로, 제3자가 자금을 이체하고 계정 간의 자금 이체를 검증해야 할 필요성이 줄어듭니다. 암호화 기술은 어음 거래소 및 기타 중간자의 역할을 대체합니다. 295 | 따라서 가상화폐는 명목화폐보다 통화 공급량 및 발행량에 대해 더욱 뛰어난 예측성을 제공할 수 있는 잠재력이 있습니다. 296 | 297 | 명목화폐 발행량 및 공급량을 발행 기관에서 광범위하게 관리하는 것이 가능한 반면, 가상화폐는 본래 고안된 방식대로만 기능할 수 있습니다. 명목화폐의 통화 공급량을 예측하는 것보다 가상화폐의 통화 공급량 및 조폐율을 예측하는 것이 더 쉬운 이유가 바로 여기에 있습니다. 298 | 299 | ![그림 1: USD 본원통화와 비트코인의 토큰 본원통화 비교](img/figure-1.jpg) 300 | 301 | *그림 1: USD 본원통화와 유명한 가상화폐(비트코인)의 토큰 302 | 본원통화 비교*[^15] 303 | 304 | 비트코인 이후로 이와 유사하거나 다른 성격의 기타 가상화폐가 탄생했습니다. 이러한 가상화폐가 한데 모여 활발하고 역동적인 시장을 형성하고 있습니다. 305 | 306 | 내림 경매 307 | ------------------------- 308 | 309 | 현재 대부분의 새로운 가상화폐는 전통적인 판매 방식을 통해 초기 지급금을 제공합니다. 이러한 판매 방식에는 보너스, 초기 구매자 가격 책정 및 구매자가 공급량을 전량 구매하도록 장려하는 기타 인센티브가 포함될 수 있습니다. 이러한 인센티브가 도움이 될 수는 있지만, 반드시 매진을 보장하는 것은 아니며 대중의 접근성이 불균형해질 수 있습니다. 이러한 모델은 지속성을 주요 목표로 하는 가상화폐에는 적합하지 않습니다. 메트로놈 개발 팀은 이러한 패턴을 지양하기 위해 다른 방법을 선택했습니다. 310 | 311 | 메트로놈 개발 팀은 메트로놈의 ICO 및 일일 공급량에 대한 모델로 내림 경매를 적용하기로 결정했으며, 이 모델은 흥미로운 기회를 제시하고 더욱 공정한 MET 분배를 가능하게 할 수 있습니다. 내림 경매를 적용하면 최초 가격이 높은 상태에서 가격이 시작됩니다. 경매가 진행되면 모든 상품이 매진되거나, 미리 설정된 하한가에 도달하거나, 경매 제한 시간 되어 경매가 종료될 때까지 가격이 낮아집니다. 각 구매자가 구매 당시 공정하다고 생각하는 가격을 지불하게 되므로 시가 예시 속도가 빠르고 공정할 것으로 판단됩니다.[^16] 구매자가 가격이 너무 높거나 불공정하다고 여길 경우, 구매자는 원하는 수준까지 가격이 낮아지기를 기다렸다가 구매할 수 있습니다(단, 공급량이 남아 있는 경우). 312 | 313 | 메트로놈 개발 팀은 고래 투자자가 너무 많은 MET 공급량을 통제하는 것을 완화하고, 경매에 평등하게 접근할 수 있는 기회를 부여하고, 더욱 공정한 MET 분배에 다가서기 위한 노력의 일환으로 이 메커니즘을 선택했습니다. 314 | 315 | 316 | 317 | 메트로놈 소개 318 | ===================== 319 | 320 | 메트로놈은 자치구조 및 지속성, 장기적인 신뢰성, 최대의 수익성을 위해 개발된 새로운 가상화폐입니다. 제도권 수준의 견고성을 보장하도록 설계된 메트로놈은 이전의 다른 가상화폐에서 얻은 교훈을 토대로 하며, 향후 100년 이상 사용할 수 있도록 고안되었습니다. 우리는 메트로놈이 1,000년간 지속 가능한 가상화폐라고 예견합니다. 321 | 322 | 메트로놈 작동 원리 323 | =================== 324 | 325 | ![그림 2](img/figure-2.jpg) 326 | 327 | *그림 2: 이더리움 블록체인에서 메트로놈 계약 간의 상호 작용 흐름* 328 | 329 | **출시** 330 | 331 | 메트로놈 개발 팀의 목표인 더욱 공정하고 평등한 경매 기회 접근 및 MET 공급량을 제공하기 위해, 메트로놈의 ICO 및 일일 공급량에는 DPA(내림 경매)가 사용됩니다. 이 모델은 전통적인 경매 방식과 다르며 약간의 설명이 필요합니다. 내림 경매의 경우, 토큰당 가격은 최고가에서 시작됩니다. 그리고 제공된 공급량이 모두 판매되거나 경매 제한 시간이 되어 경매가 종료될 때까지 가격이 점차 낮아집니다. 메트로놈은 투명하고 예측 가능한 가격 책정을 구현하기 위한 332 | 노력의 일환으로 DPA를 적용합니다.[^17] 333 | 334 | ICO의 시작 가격은 MET당 2 ETH입니다. 경매가 공개되어 있고 구매 가능한 MET 수량이 아직 남아 있다면 가격은 60초당 0.0001984320568 ETH씩 낮아지며 하한가는 0.0000033 ETH입니다. 335 | 336 | 구매자는 메트로놈 가상화폐를 실시간으로 구매하며 구매 직후 바로 메트로놈이 지급됩니다. ICO 동안 구매한 메트로놈은 ICO가 종료되기 전까지는 이체할 수 없으나, 일일 공급량을 통해 구매한 메트로놈은 지급받은 즉시 이체할 수 있습니다. 337 | 338 | 메트로놈 개발 팀은 이러한 방식으로 경매를 시행할 경우 구매자가 공정하다고 여기는 가격으로 MET를 구매할 수 있는 기회가 제공된다고 봅니다. 물론 이는 해당 가격으로 MET를 구매할 수 있다는 조건을 전제로 합니다. 또한, 내림 경매는 "모두에게 최종 가격이 적용되는" 순수 역경매보다 더 정확한 시가 예시를 제공할 것으로 전망됩니다. 그 이유는 구매자가 해당 가격보다 높은 가격을 지불할 용의가 있을 경우, 본질적으로 최종 가격이 저평가되기 때문입니다. 339 | 340 | 이 방법은 MET를 불균형하게 대량 구매할 경우 새로운 시장 가격보다 비싸게 구매하게 될 가능성이 있으므로, 고래 투자자 및 여타 대형 투자자가 경매에서 막대한 양의 MET를 쓸어갈 기회를 줄일 수도 있습니다. 순수 역경매는 초기 구매자에게 여전히 불균형한 방식으로 MET를 분배합니다. 341 | 342 | 수많은 공급량 구매 시나리오가 가능할 수 있으나, 한 가지 강조하고 싶은 상황은 점진적인 흐름 뒤에 갑자기 구매량이 쇄도하는 경우입니다. 이 시나리오에서 구매자들은 소량의 공급량을 높은 가격으로 구매합니다. 그러다 가격이 어느 임계값 아래로 떨어지면 나머지 공급량이 급격하게 소진될 수 있습니다. 343 | 344 | **1단계: ICO** 345 | 346 | - ICO로 토큰 10,000,000개가 할당됩니다. 347 | 348 | - ICO 중 20%는 설립자가 보유합니다. 349 | 350 | - 특수 TokenLocker 계약에 대해 발행됨(API 섹션 참조) 351 | 352 | - ICO 종료 시 개발자가 25% 사용 가능 353 | 354 | - 나머지 75%는 12분기에 걸쳐 12번씩 균등한 수량으로 제공 가능 355 | 356 | - 메트로놈 개발자만이 TokenLocker 계약에서 인출할 수 있으며, 상기 지정된 시간에만 가능 357 | 358 | - 토큰 8,000,000개(MET 10,000,000개의 총 초기 토큰 공급량에서 설립자가 보유한 20%의 토큰 공급량을 뺀 수량)의 내림 경매로 진행됩니다. 359 | 360 | - ICO는 최대 7일간 지속됩니다. 361 | 362 | - ICO 가격은 MET당 2 ETH로 설정되며, 하한가는 0.0000033 ETH로 설정됩니다. 363 | 364 | - ICO에서 MET 경매 가격은 60초마다 0.0001984320568 ETH씩 연속적으로 낮아집니다. 365 | 366 | - 경매는 전체 8,000,000개의 토큰 재고가 매진되거나 경매가 7일(10,080분)을 경과하여 종료될 때까지 지속됩니다. 367 | 368 | - ICO 수익금의 100%는 수익금 계약에 저장됩니다. 369 | 370 | **2단계: 운영 통화** 371 | 372 | - 이전 경매가 종료된 후에는 24시간마다 새로운 토큰이 일일 공급량에 무제한으로 추가되며 (i) 하루 2,880개의 MET 또는 (ii) 연간 남은 공급량의 2.0000%(연율)에 해당하는 수량 중 더 큰 수량을 내림 경매 방식으로 판매합니다. 373 | 374 | - 24시간마다 경매가 시작되며, 경매 중복을 방지하기 위해 24시간 이상 지속되지 않습니다. 375 | 376 | - 일일 공급량에서 모든 토큰의 내림 경매는 이전 경매 종료 가격의 최대 2배에서 시작됩니다(*예*: 경매 매진 시 마지막으로 판매된 토큰의 가격 또는 경매 제한 시간에 도달했을 때의 가격). 377 | 378 | - 지정된 일일 공급량에서 메트로놈의 판매량이 0개인 경우, 그 다음날 일일 공급량의 가격은 *일일 공급량 경매에서 메트로놈이 판매된* 마지막 가격의 1/100에서 시작됩니다. 379 | 380 | - 60초마다 경매 가격은 이전 가격의 99%로 낮아집니다. 381 | 382 | - 경매는 (i) 전체 일일 공급량 재고가 매진되거나, (ii) 경매 시작 후 24시간이 지날 때까지 지속되며, 둘 중 더 빠른 경우가 우선 적용됩니다. 383 | 384 | - 일일 공급량 재고가 완전히 매진되지 않을 경우, 모든 나머지 MET가 다음날 일일 공급량에 추가됩니다. 385 | 386 | - 모든 일일 공급량 경매의 절대 하한가는 1 Wei입니다. 387 | 388 | - 일일 공급량의 100%는 수익금 계약에 사용됩니다. 389 | 390 | - 24시간마다 수익금 계약의 총 누적 잔액의 0.25%를 자율환산계약(Autonomous Converter Contract)으로 보내(아래에 설명됨) MET 보유자가 원할 경우 MET를 매도할 수 있는 추가 옵션을 제공합니다. 391 | 392 | 크로스 블록체인 호환성 393 | ---------------------------- 394 | 395 | 396 | ![그림 3](img/figure-3.jpg) 397 | 398 | *그림 3: 크로스 블록체인 호환성에 대한 설명* 399 | 400 | 메트로놈의 고유한 기능 중 하나는 체인 간 호환성으로, 사용자는 이를 통해 어떤 이유로든 MET를 한 블록체인에서 다른 블록체인으로 옮길 수 있습니다. MET를 옮기기로 결정한 경우 사용자는 MET가 전송될 목적지인 대상 블록체인에 커밋해야 합니다. 사용자가 소스 블록체인 A의 토큰 공급량에서 MET를 제거하면 "출금 증명" 머클[^18] 영수증을 수신합니다. 그 다음 단계로, 사용자는 대상 블록체인 B의 메트로놈 계약에 이 영수증을 제공합니다. 401 | 402 | 이 시나리오의 경우, 이러한 내보내기/가져오기 프로세스를 통해 블록체인 A의 MET 토큰 공급량이 줄어들고 블록체인 B의 토큰 공급량이 늘어납니다. 자율적인 일일 공급량은 두 블록체인 A와 블록체인 B에 비례하여 조정되어 블록체인 A와 B 전체의 새로운 MET 분배가 반영됩니다. 예를 들어 블록체인 A에 총 MET의 50%가 존재하고 블록체인 B에 총 MET의 50%가 존재할 경우, 체인 A의 일일 경매에서 하루에 발행되는 토큰은 1,440개여야 하고, 체인 B의 일일 경매에서 하루에 발행되는 토큰은 1,440개여야 합니다. 403 | 404 | 내보내기/가져오기 시스템 405 | ---------------------------- 406 | 407 | 408 | 메트로놈은 다른 블록체인을 이용하기 때문에 더욱 자치구조가 견고하고 지속성이 우수합니다. 체인에 영구성이 부족하면 단일한 블록체인으로 된 암호화폐보다 글로벌 공급량과 같은 상수를 유지하기가 더 어려워집니다. 그렇기 때문에 메트로놈의 가져오기 및 내보내기 기능은 초기에 세 단계로 전개될 것입니다. 블록체인 기술이 계속 발전하면서 단계가 추가되어 메트로놈 생태계를 더욱 분산화하고 보강할 수 있습니다. 409 | 410 | 메트로놈의 이동성을 이루는 상위수준 구성요소는 다음과 같습니다. 411 | 412 | **내보내기** 사용자는 내보내기 기능을 호출하여 MET를 한 체인에서 다른 체인으로 이동시킬 수 있습니다. 이 기능은 사용자의 MET를 가져와 로컬 체인에서 소각하고 머클 영수증 형태의 ExportReceipt를 사용자에게 발급합니다. 소유자는 MET에 약간의 수수료를 지불하고 검증자가 이를 청구하게 됩니다. 이 영수증을 이용하여 대상 체인에서 MET를 청구할 수 있어서 소유자의 MET를 한 체인에서 다른 체인으로 효과적으로 옮길 수 있게 됩니다. 413 | 414 | **가져오기** 사용자가 원하는 대상 메트로놈 계약에 ExportReceipt를 제공할 수 있습니다. importMET를 호출하고 ExportReceipt를 제공합니다. 처리를 마치면 대상 체인은 MET를 원 수령자에게 전달합니다. 메트로놈 가져오기를 마친 사용자는 영수증을 제시하여 위에서 언급한 수수료를 MET로 수령할 것입니다. 415 | 416 | 그렇지만 메트로놈은 다수의 체인으로 이루어질 것이기 때문에 이들 체인들에는 데이터소스가 산재해 있게 됩니다. 그러므로 가져오기와 내보내기에 검증이 필요합니다. 417 | 418 | **검증** 가져오기와 내보내기 과정에서 검증자가 다음과 같은 역할을 해야 합니다. 419 | 420 | 하드포크가 있을 때 어떤 체인이 유효한지 증명합니다. 421 | 422 | 특정한 가져오기를 검증하기 위해 추가적인 정보를 제공합니다(이벤트 증거 등). 423 | 424 | 메트로놈의 가져오기/내보내기 인프라는 세 단계로 전개될 것입니다. 메트로놈 v1로 출시하고 향후에는 기존 메트로놈 계약에 대한 업그레이드가 이루어질 것입니다. 425 | 426 | 개념적으로 볼 때, 검증자는 메트로놈 생태계에서 다른 암호화폐의 '채굴자(miner)'와 비슷한 역할을 합니다. 검증자는 메트로놈에 산재되어 있는 데이터소스를 검증하고 인증합니다. 내보낸 사용자는 검증자의 노력에 대해 선택적인 수수료를 MET로 지불하게 됩니다. 427 | 428 | 검증 단계의 시스템 디자인(아래에 설명)은 다음을 보장합니다. 429 | 430 | 메트로놈의 글로벌 공급량이 절대로 일일 10,000,000개 + 2880개(또는 연간 공급량 누적의 2%)를 넘지 않도록 합니다. 431 | 432 | 검증자는 개별 거래를 검열할 수 없습니다. 433 | 434 | 검증자들은 서로 동의하도록 권장됩니다(아래 참조). 435 | 436 | 다른 체인에 있는 메트로놈 계약은 불일치를 탐지하고 불안전한 블록체인에 '표시'를 하여, 궁극적으로는 식별된 문제를 해결할 때까지 그러한 체인을 격리시킬 수 있습니다. 437 | 438 | 검증 단계 439 | ---------------------------- 440 | 441 | 1단계 검증자는 ExportReceipt 해시를 통해 각각의 ExportReceipt를 확인하고 검증합니다. 충분한 수의 검증자들이 어떤 해시가 유효하다고 합의하면, 검증된 영수증을 통해 누구나 메트로놈을 가져올 수 있습니다. 442 | 443 | 2단계 검증자는 모든 ExportReceipt의 히스토리 리스트를 유지하고 영수증들의 해시로 이루어진 머클 트리를 생성한 후에 그러한 트리의 머클 루트를 검증합니다. 가져오기 사용자는 가져오기 증거를 검증자와 사용자에게 제공합니다. 가져오기 증거는 머클 영수증과 이벤트의 루트를 증명하는 해시 쌍으로 구성됩니다. 444 | 445 | 3단계 검증자는 메트로놈이 있는 모든 체인의 블록체인 해시를 검증합니다. 가져오기 사용자는 다음과 같은 증거를 제공합니다. 446 | 447 | - 내보내기 이벤트가 머클 경로를 통한 내보내기 체인의 특정 블록 헤더에 있다는 증거 448 | 449 | - 블록 이벤트가 검증된 체인 해시에 해당한다는 증거 450 | 451 | 보증 및 불량 행위자에 대한 안전조치 452 | ---------------------------- 453 | 454 | 검증된 행위자가 스스로를 증명하는 1단계 검증 모델처럼, 커뮤니티와 개발 팀은 계속적으로 검증 메커니즘을 더욱 분산시킬 것입니다. 현재 가장 바람직한 분산화 수준은 3단계 이상일 것입니다. 검증 모델을 더욱 분산화시키면 여러모로 안전성이 강화되지만 비이성적인 이유로 악의적인 행동을 할 가능성이 상존합니다. 이에 대응하기 위해서는 시스템 아키텍처에 그리핑(griefing), 체인 간 공격, 다른 메트로놈 세트에 있는 버그, 다양한 기타 사기 또는 오류 문제에 대한 내성이 있어야 합니다. 455 | 그러한 시스템은 아직 규정 중이지만, 개략적으로 말씀드리면 메트로놈 개발 팀은 지분증명(Proof of Stake) 시스템의 몇 가지 핵심 개념들과 작업증명(Proof of Work) 개념을 조합하여 활용할 것입니다. 메트로놈은 불량 행위자에게 대해 유연한 조치와 강력한 조치를 동시에 사용할 계획입니다. 메트로놈은 공급량을 고정시키고, 사용자가 메트로놈 세계의 어느 부분이 안전한지를 알고, 자신의 MET를 안전한 곳으로 내보낼 수 있게 한다는 기본 원칙을 갖고 있습니다. 456 | 457 | 458 | 분산된 자발적 합의 관리 459 | ------------------------------------------- 460 | 461 | MET 보유자 커뮤니티의 자발적 합의를 기반으로 개발자가 출시한 최초의 '시초' 체인에서 메트로놈을 내보내고, 개발자 또는 다른 당사자가 릴리스한 후속 업그레이드에 메트로놈을 가져올 수 있는 기능은 변경 불가능한 계약, 그리고 시장의 발전에 따라 이러한 계약을 업그레이드할 수 있는 공정한 분산 메커니즘을 제공합니다. 462 | 463 | 예를 들어 시장의 수요가 공급량을 크게 초과하고 원본 MET의 실제 가격이 매매자가 감당할 수 있는 현실적인 수준을 넘을 경우, 일부는 수중에 관리 중인 자금을 새로운 포크에 내보내는 방식을 통해 새로운 MET 계약에 따라 MET 공급량을 동일한 체인이나 다른 체인으로 분리하는 데 동의할 수 있습니다. 이렇게 하면 새로운 변경 불가한 MET 계약은 상업적 활용도가 더 높은 업그레이드된 토큰 공급량 곡선을 가질 수 있기 때문에 원래의 토큰 공급량 곡선이 갖는 위험을 제거할 수도 있습니다. 464 | 465 | 이와 마찬가지로 오랫동안 시장의 공급량이 수요보다 많고 가격이 하락할 경우, 서로 다른 분리된 체인의 MET 보유자들은 여러 내보내기 소스를 하나의 가져오기 대상으로 '병합'하는 데 동의할 수 있습니다. 이러한 자발적 합의 메커니즘을 통해 경제적으로 유효한 총 MET 공급량을 줄이면 수요 감소 시 토큰 공급량이 줄어들기 때문에 안정적인 가격이 유지됩니다. 466 | 467 | 새로운 체인으로의 분리와 이전이 MET 토큰 공급량 곡선과 발행에 어떠한 영향을 미치는지는 메트로놈 커뮤니티가 풀어야 할 숙제입니다. 앞으로 직접적인 참여를 통해 새로운 MET 대상 계약을 정의, 구현, 분리, 병합하고, MET을 새로운 계약에 가져오고, 어떤 결과가 발생하는지 함께 지켜봐 주시기 바랍니다. 468 | 469 | 470 | 가상화폐 시장 현황 471 | ===================================== 472 | 473 | 메트로놈이 가상화폐 세계에 어떤 방식으로 적합한지 보다 잘 이해하려면 전반적인 환경을 세부적으로 살펴보아야 합니다. 474 | 475 | 환경 476 | ------------- 477 | 478 | 몇 가지 유명한 가상화폐와 토큰 공급량, 발행표, 이러한 발행표의 경제적 탄력성 및 변동 저항성을 살펴보겠습니다. 479 | 480 | ![그림 4](img/figure-4.jpg) 481 | 482 | *그림 4: 현재 유명한 가상화폐의 발행율(참고: ETH는 예상치임)*[^19] 483 | 484 | Bitcoin("비트코인" 또는 "BTC")은 2009년 1월 5일에 개시되었으며 대중에게 공정한 채굴 및 생태계 참가 기회를 제공합니다.[^20] 새로운 통화 공급량이 모든 블록마다 추가되었습니다. 블록 목표 주기는 2,016개의 블록마다 블록당 10분입니다. 공급 발행량은 블록당 50 BTC로, 4년마다 절반씩 줄어듭니다. 485 | 486 | 비트코인 커뮤니티는 2100만 개로 제한된 비트코인 통화 공급량의 불변성, 그리고 발행표의 불변성에 높은 가치를 둡니다. 이 한도에 도달하면 새로운 BTC 채굴은 중단되며, 가능할 경우 채굴자에게는 거래 수수료가 인센티브로 제공됩니다. 공급 발행량이 이처럼 경미한 수준으로 감소할 시, 거래 수수료가 비트코인을 유지할 충분한 자금력과 보장성을 제공할지 여부는 비트코인 커뮤니티 내에서도 많은 논쟁이 있습니다.[^21] [^22] 비트코인이 오늘날 처음부터 다시 발행된다면, 현재의 절대적인 디플레이션 특성을 오래 지속되는 완만한 인플레이션 특성으로 바꾸어 향후 네트워크를 영구적으로 보장할 수 있을 만큼의 인센티브를 채굴자에게 제공할 수 있을까요? 아마 가능할 겁니다. 낮은 인플레이션율은 리소스 독점을 완화하여 가상화폐 투자를 *장려*하고 채굴을 통한 블록체인의 지속적인 보안을 실현하므로, 바람직하다고 할 수 있습니다.[^23] 487 | 488 | ![그림 5](img/figure-5.jpg) 489 | 490 | *그림 5: 비트코인과 메트로놈의 발행량 및 유통 공급량 비교*[^24] 491 | 492 | 발행표의 예측 가능성 및 불변성은 오늘날 사용자가 신뢰하고 있는 요소입니다. 예측 가능성은 시장 이용자가 수년, 혹은 앞으로 수십 년에 걸친 계획을 세울 수 있도록 합니다. 불변성은 통화 공급량이 사람의 변덕이나 약한 마음에 의해 변동되지 않도록 보장합니다. 그러나 비트코인은 다양한 그룹이 네트워크 관리에 영향력을 행사하는 데 관심을 갖고 있으므로, 비트코인 커뮤니티는 논쟁적인 분리, 불확실성, 구경거리에 휘말리곤 합니다. 493 | 494 | Litecoin("라이트코인" 또는 "LTC")은 비트코인을 본따 만든 화폐입니다.[^25] 블록 목표 주기는 블록당 2.5분입니다. 공급 발행량은 블록당 50 LTC로, 4년마다 절반씩 줄어듭니다. 라이트코인은 통화 발행 측면에서 보았을 때 비트코인의 상당 부분을 모방했습니다. 대부분의 커뮤니티에서 발행표는 변경 불가능한 것으로 간주됩니다. 새로운 공급량 발행은 비트코인과 마찬가지로 시간이 경과할수록 감소합니다. 라이트코인의 관리 방식은 비트코인과 유사하지만 생태계 내의 상징적 아이콘을 관례적으로 존중하는 부분이 있습니다. 495 | 496 | Zcash("제트캐시" 또는 "ZEC")는 유사한 방식으로 기능합니다. 작업 증명 채굴 기회를 모두에게 부여합니다. 블록 목표 주기는 블록당 2.5분입니다. 공급 발행량은 블록당 12.5 ZEC로, 4년마다 절반씩 줄어듭니다. 특수한 경우로서, 최초 20,000개의 블록은 전체 12.5 ZEC 방출률에 이를 때까지 느리게 증가합니다. 개발 팀과 지원 프로토콜 개발 팀은 일회성 보상 대신 10% 설립자 토큰 공급량 보상을 받습니다. 이는 출시 후 4년에 최초의 반감기가 올 때까지 모든 블록에 적용됩니다. 이 시점이 지나면 발행된 토큰 공급량의 100%가 채굴자에게 제공됩니다.[^26] Zcash Foundation은 생태계의 자발적 관리를 위한 자연 발생적 중심지입니다. [^27] 497 | 498 | ![그림 6](img/figure-6.jpg) 499 | 500 | *그림 6: ZEC 개발자와 MET 개발자의 보유율 대 유통 공급량 비교 501 | *[^28] 502 | 503 | Ethereum("이더리움" 또는 "ETH") 사전 판매는 60,000,000 ETH 이상으로 증가했으며, 이는 시초 블록으로 사전 채굴되었습니다.[^29] [^30] 새로운 공급량(5 ETH)이 모든 블록마다 추가되었습니다. 새로운 통화 공급량은 T+1Y에 19.8% 증가했으며 T+2Y에는 21.2%, T+3Y에는 17.4%입니다. 공급량 증가는 이 시점부터 감소합니다. 이더리움 통화 발행표는 유동적인 것으로 알려져 있으며, 시스템 발전에 따라 변동될 수 있습니다.[^31] 이더리움은 지분 증명을 변경할 예정이므로 발행량도 변동될 것입니다.[^32] 따라서 탄력성 및 지속 가능성 목표에 따라 발행량이 변동될 수 있습니다. 모든 변경 사항은 커뮤니티 및 채굴자의 지지를 받아야 하지만, 소규모 설립 팀에 대한 관례적 존중과 의존도가 여전히 높은 편입니다. 504 | 505 | Ripple("리플" 또는 "XRP")의 제공 가능한 공급량은 380억 XRP입니다.[^33] 관리 회사인 Ripple, Inc.는 추가로 610억 XRP를 보유하고 있으며, Ripple Inc는 그 중 550억 XRP를 에스크로에 보관하고 있습니다.[^34] 이는 해당 가상화폐 생태계의 대부분을 Ripple Inc.가 제어하는 방식으로 중앙에서 관리됩니다. Ripple Inc.는 시장에 유입되는 공급 발행량을 직접 관리하며, 따라서 XRP는 변동성이 높습니다. Ripple Inc는 불균형한 관리 기능을 보유하고 있습니다. 506 | 507 | 메트로놈은 이러한 디지털 통화로부터 얻은 교훈을 토대로 하며 그 결과 제도권 수준의 견고성을 보장하는 가상화폐를 고안해냈습니다. 메트로놈의 구조는 발행, 관리, 신뢰성을 주요 원칙으로 합니다. 메트로놈은 자치구조의 당초 설계 목표를 개발자가 부당하게 변경하지 못하도록 하는 100% 자율적인 화폐입니다. 메트로놈은 예측을 할 수 있으며 예측 가능한 속도로 새로운 MET를 발행하므로 안정적입니다. 사용자가 어떤 이유로든 합당하다고 여기는 경우 블록체인 간에 가져오기 및 내보내기가 가능한 호환성도 지원합니다. 508 | 509 | 510 | | | BTC[^35] | LTC[^36] | ETH[^37] | XRP[^38] | ZEC[^39] | MET | 511 | |--|--|--|--|--|--|--| 512 | | **신뢰성** | BTC는 논쟁적인 분리와 디플레이션으로 유명합니다. 토큰 공급량 및 발행량은 안정적이지만 유한합니다. | BTC와 마찬가지로, LTC의 발행량 및 토큰 공급량은 제한적이므로, 체인의 안정성을 위협할 수 있습니다. | ETH의 발행량 및 토큰 공급량은 유동적입니다. 과거에 분리된 적이 있습니다. | XRP는 공급량이 안정적입니다. Ripple Inc.에서 전적으로 관리합니다. | BTC와 마찬가지로, ZEC는 발행량이 제한되어 있으므로 향후 체인의 안전에 의문을 제기할 수 있습니다. | **MET 발행량 및 공급량은 계약에 정의된 대로 예측 가능한 수준으로 무제한 유지됩니다. 공급량이나 발행량에 대한 불확실성이 없습니다.** | 513 | | **자치구조** | BTC는 자체적으로 관리되지만 많은 그룹이 과도한 영향력을 행사하려고 합니다. | LTC는 자체적으로 관리되지만 상징적 아이콘을 관례적으로 존중하는 경향이 있습니다. | ETH를 변경하려면 커뮤티니의 지지가 필요하지만, 소규모 팀에 대한 의존도가 높습니다. | XRP는 자체 관리되지 않습니다. Ripple Inc에서 XRP에 대한 전적인 관리 권한을 보유합니다. | Zcash Foundation은 자발적 관리를 위한 자연 발생적 중심지입니다. | **MET는 자율 계약을 통해 전적으로 자체 관리됩니다.** | 514 | | **호환성** | 미지원 | 미지원 | 미지원 | 미지원 | 미지원 | **지원** | 515 | | **불변성** | 강력함 | 강력함 | 변동 가능, PoS로 변경 예정 | 약함 | 강력함 | **강력함** | 516 | | **발행 모델** | 10분당 50 BTC. 4년마다 절반씩 감소. | 2.5분당 50 LTC. 4년마다 절반씩 감소. | 15초당 5 ETH. | Ripple Inc에서 한 번에 발행됨 | 2.5분당 12.5. 4년마다 절반씩 감소. | **MET는 매일 (i) 하루 2,880개의 MET 또는 (ii) 연간 남은 공급량의 2.0000%(연율)에 해당하는 수량 중 많은 수량을 경매 방식으로 판매** | 517 | | **공급량 한도** | 2100만 | 8400만 | 알 수 없음 | 1000억 | 2100만 | **위의 발행 모델 참조** | 518 | | **결제 시간** | 10분 | 2.5분 | 15초 | 5초 | 2.5분 | 15초 | 519 | | **대량 지급 기능** | 지원 | 지원 | 미지원 | 미지원 | 지원 | **지원** | 520 | | **구독 기능** | 미지원 | 미지원 | 미지원 | 미지원 | 미지원 | **지원** | 521 | 522 | *표 1: 오늘날 523 | 가상화폐* 간의 중요특성 비교 524 | 525 | 메트로놈 계약 및 기술적 측면 526 | ========================================= 527 | 528 | 메트로놈은 네 가지 자율 스마트 계약으로 구성되며 일반적인 흐름은 다음과 같습니다. 529 | 530 | 1. 첫 번째 계약은 MET 토큰 및 원장으로, 블록체인과 직접 상호 작용합니다. 이는 사용자가 P2P 거래를 수행하는 방식이며 자산의 분산 저장 수단으로 사용할 수 있습니다. 이는 개선된 보안 및 이체를 위한 맞춤 기능을 포함하는 ERC20 토큰 표준과 유사합니다. 531 | 532 | 2. 토큰 계약의 다음 단계는 경매 계약입니다. 사용자는 경매 계약을 통해 MET를 구매합니다. 사용자가 경매 계약을 통해 구매를 하면, 해당 계약에 따라 사용자에게 MET가 발행됩니다. 533 | 534 | 3. 그런 다음, 경매 계약은 수익금을 세 번째 계약인 수익금 계약으로 전송합니다. ICO 및 각 일일 공급량의 수익금은 경매 계약에서 수익금 계약으로 100% 전송됩니다. 535 | 536 | 4. 24시간마다 수익금 계약은 계약 내용의 0.25%를 네 번째 계약인 자율환산계약(Autonomous Converter Contract)으로 전송하며, 이는 사용 가능한 ETH를 제공합니다. 사용자가 ETH 또는 MET를 자율환산계약에 전송하면 이 계약은 각각 계약에 정의된 비율로 MET 또는 ETH를 반환합니다. 자율환산계약의 토큰 비율은 토큰의 상대값을 결정하므로, 차익 거래로 가격을 거의 정확하게 유지할 수 있을 것으로 예상됩니다. 계약에 MET(또는 ETH)가 너무 적은 경우, 해당하는 쌍에 비해 가격이 비싸집니다. 자신의 MET(또는 ETH)이 그만한 가치가 없다고 생각하는 사용자는 토큰을 다른 토큰과 교환하려고 할 것이므로 이를 통해 계약 내용의 균형을 맞출 수 있으므로, 상대적 가격 불균형이 정정됩니다. 537 | 538 | 메트로놈 수익금 및 자율환산계약 539 | ===================================================== 540 | 541 | 모든 경매의 모든 수익금은 메트로놈 생태계에서 유지되며, 이는 메트로놈 및 사용자를 위한 견고한 생태계를 구축하기 위한 것입니다. 경매의 모든 수익금이 계약의 체인에서 유지되고 다른 그룹의 통제에서 벗어나 있으므로, 메트로놈은 더욱 폭넓고 자율적인 지속성을 유지할 수 있을 것으로 기대됩니다. 542 | 543 | 이러한 흐름의 첫 시작 단계는 계약 구매자가 경매에서 MET를 구매할 때 상호 작용하게 되는 경매 계약입니다. 그 다음, 수익금 계약에 경매 계약의 수익금을 전송하고 그 일부를 자율환산계약(Autonomous Converter Contract)에 내보내어, 매매에 사용할 수 있는 ETH 공급량을 자율환산계약에 제공합니다. 초기화 시 자율환산계약에는 하나의 MET가 존재하게 됩니다. 544 | 545 | ICO 및 모든 후속 일일 공급량에서 수익금의 100%가 수익금 계약으로 전송됩니다. 수익금은 메트로놈 개발자에게 분배되지 않습니다. 수익금 계약은 매일 총 누적 수익금의 0.25%를 자율환산계약에 전송합니다. 이렇게 하면 자율환산계약에 직접 영수증을 제공하는 방식과 비교했을 때, 일일 경매량의 변동을 해결할 수 있을 것으로 예상됩니다. 546 | 547 | ETH를 자율환산계약에 매도할 경우, 계약에 있는 특정한 양의 ETH로 얻을 수 있는 MET의 양이 증가합니다. MET를 매도하여 ETH를 구매하려는 경우 이러한 매도자에게는 더 많은 ETH가 제공되며, 자율환산계약을 사용하여 MET를 구매하려는 경우 더 많은 ETH를 지불해야 합니다. 548 | 549 | 자율환산계약의 일일 ETH 매도량으로 인해 시장에서 허용 가능한 수준 이상으로 MET 값이 증가하는 범위 내에서는, 차익 거래가 과도한 ETH를 억제할 것으로 전망됩니다. 그러나 메트로놈의 예측 가능성은 수십 년간의 기간을 두고 측정되므로, 시장에서 자율환산계약에 대한 ETH 가용성의 흐름을 예측하고 가격을 책정할 수 있을 것으로도 예상됩니다. 550 | 551 | ![그림 7](img/figure-7.jpg) 552 | 553 | *그림 7: 자율환산계약과 상호 작용 중인 사용자 경험 및 자율환산계약의 백엔드 프로세스* 554 | 555 | **경제적 예측** 556 | 557 | 자율환산계약은 시장에 의해 결정된 가격에 대한 접근 방식을 추구하는 반면, 경매 계약은 매일 가격 책정표가 고정되어 있습니다. 그 결과는 다음과 같습니다. 558 | 559 | - 경매의 토큰 가격이 자율환산계약보다 높을 경우, 구매자는 경매를 통해 토큰을 구매할 가능성이 낮을 것으로 예상됩니다. 구매자는 자율환산계약을 통해 가격이 더 싼 토큰을 구매하는 것이 나을 수 있습니다. 560 | 561 | - 경매의 토큰 가격이 자율환산계약보다 낮을 경우 모든 참가자는 경매에서 구매를 통해, 그리고 자율환산계약에 토큰을 매도하여 차익을 얻을 수 있습니다. 이렇게 하면 자율환산계약의 모든 ETH 불균형에서 차익을 얻을 수 있습니다. 그러나 모두가 이 방법을 원하므로, 가격 차이가 커지기 전에 경매가 매진될 것으로 예상됩니다. 562 | 563 | 요약하자면, 경매의 구매자는 자율환산계약의 현재 가격과 매우 근사한 가격으로 경매에서 토큰을 구매하고자 할 것으로 예상됩니다. 그리고 구매자는 매일 조기 구매자로부터 수익을 얻을 수 있으며, 경매에서 전혀 구매를 할 수 없다는 위험에 대한 대가를 지급받게 됩니다. 564 | 565 | 일일 공급량이 매진되면 자율환산계약에 매도하여 과도한 공급을 충족할 수 있으므로, 토큰 가격이 증가할 수 있습니다. 내림 가격은 결국 시장 가격 이하로 떨어지기 때문에 각 경매는 매진될 것으로 예상됩니다. 566 | 567 | **수식** 568 | 569 | 사용자가 자율환산계약으로 거래할 경우, 사용자는 토큰 공급량 간의 비율을 사용하지 않으므로 항상 가격 하락이 발생합니다. 공식이 모든 가격을 결정하기 때문에, 사용자가 적은 양을 여러 번 구매하거나 한 번의 대규모 거래를 수행하는 경우와 관계없이 모두 같은 결과가 나옵니다.[^40] 570 | 571 | 여기에는 두 가지 공식이 있습니다. 한 공식은 사용자에게 MET 또는 ETH로 제공되는 스마트 토큰의 개수를 계산하고, 나머지 공식은 사용자에게 스마트 토큰으로 제공되는 MET 또는 ETH의 수량을 결정합니다. 스마트 토큰은 사용자에게 공개되지 않습니다. 572 | 573 | 정확하고 효율적인 "기본 함수"를 작성하는 것은 중요한 개발 과제입니다. 이더리움에는 256비트 정수만 있으므로 새로운 구현 방식이 필요합니다. 574 | 575 | 비축률을 0.5로 정하고 자율환산계약을 두 가지 가상화폐(MET 및 ETH)로 제한하면 수식이 간단해지고 제곱근이 하나만 있으면 되므로, 간단한 구현과 매우 효율적인 실행이 가능합니다. 576 | 577 | 수식은 다음과 같습니다. 578 | 579 | *R* = 비축 토큰 잔액 580 | 581 | *S* = 스마트 토큰 공급량 582 | 583 | *F* = 상시 비축률 584 | 585 | *T* = 비축 토큰 E와 교환하여 지급되는 스마트 토큰 586 | 587 | *E* = 스마트 토큰 T와 교환하여 지급되는 비축 토큰 588 | 589 | 원본 공식은 다음과 같습니다.[^41] 590 | 591 | *T* = *S*((1 + $\frac{E}{R}$)${{}^{}}^{F} - 1$) 592 | 593 | *E* = *R*(1 - (1 - $\frac{T}{S}$)${}^{\frac{1}{F}}$) 594 | 595 | 이 경우에서는 F가 0.5로 설정되어 있으므로 고정 소수점 곱셈, 나눗셈, 제곱근으로 수식을 사용할 수 있습니다. 596 | 597 | *T* = *S*($$) - 1) 598 | 599 | *E* = *R*(1 - (1 - $\frac{T}{S}$)${}^{2}$) 600 | 601 | **예제** 602 | 603 | 자율환산계약에 1,000개의 ETH, 2,000개의 MET가 있고 10,000개의 스마트 토큰이 있다고 가정해보겠습니다. 자율환산계약의 MET 가격은 0.50 ETH입니다. 사용자는 이 가격이 높은 편이라고 생각하며 100개의 MET를 ETH로 교환하고자 합니다. 이 경우 현재 명목 가격에 따라 50 ETH가 반환되지만, 가격 하락으로 인해 사용자가 실제로 얻는 수량은 더 적습니다. 604 | 605 | **1단계**: 100개의 MET를 스마트 토큰으로 교환합니다. 606 | 607 | T?=?S?(v1+ E/R)-1) 608 | 609 | T? = 10000( v1 + 100/2000 ) - 1) = 10000( v1.05 - 1) = 10000(1.0247 - 1) = 10000(0.0247) = 247 610 | 611 | 사용자는 새로 발행된 스마트 토큰 247개를 받습니다. 스마트 토큰의 총 공급량은 이제 10,247개입니다. 자율환산계약에서 보유하게 된 총 MET 공급량은 이제 2,100개입니다. 612 | 613 | **2단계**: 스마트 토큰 247개를 ETH로 환산합니다. 이는 계약에 의해 자동으로 이행되며, 사용자에게는 스마트 토큰이 공개되지 않습니다. 614 | 615 | 1000 ETH인 경우 공식의 비축 공급량은 다음과 같습니다. 616 | 617 | *E* = *R*(1 - (1 - $\frac{T}{S}$)${}^{2}$) 618 | 619 | *E* = 1000(1 - (1 - $\frac{247}{10247}$)${}^{2}$) = 1000(1 - (1 - 0.0241)${}^{2}$) = 1000(1 - .976${}^{2}$) = 1000(1 - 0.953) = 1000(0.047) = 47 620 | 621 | 사용자는 100개의 MET로 47개의 ETH를 받습니다. 622 | 623 | 이제 계약에 953개의 ETH 및 2,100개의 MET 또는 MET당 0.45 ETH가 포함됩니다. 사용자가 일부 MET를 매도하여 자율환산계약에서 ETH 대비 MET의 가격이 낮아졌습니다. 사용자는 초기 가격과 최종 가격의 중간쯤에 해당하는 ETH를 받습니다. 624 | 625 | 스마트 토큰 247개는 교환 시 폐기되므로, 스마트 토큰 공급량은 다시 10,000개로 줄어듭니다. 626 | 627 | **거래 주문 완화** 628 | 629 | 사용자는 다른 거래가 앞서 실행된 경우를 제외하고, 거래의 결과를 예측할 수 있습니다. 이를 보증할 수 있는 방법은 없습니다. 실제로, 진행 중인 거래를 다른 당사자가 볼 수 있으며, 거래 주문을 발행할 수 있습니다. 특히 채굴자는 이러한 작업을 매우 효과적으로 수행할 수 있습니다. 630 | 631 | 거래 주문에 대한 위험을 완화하려면 사용자가 최소 수익률을 지정해야 합니다. 사용자가 거래에서 최소한 그만큼의 수익을 얻지 못할 경우, 거래가 롤백됩니다. 그리고 사용자는 거래 실행에 사용된 연산 비용을 상쇄할 소량의 거래 수수료만 지불합니다. 632 | 633 | 토큰 공급량의 경제학 634 | ====================== 635 | 636 | 이론 637 | ------ 638 | 639 | - 공급량의 예측 가능성은 시장 참가자가 향후 12개월, 5년, 50년간 공급량을 정확하게 측정할 수 있도록 함 640 | 641 | - 가격은 내림 경매를 통해 결정됨 642 | 643 | **공급량** 644 | 645 | - ICO: 내림 경매를 통한 토큰 10,000,000개 646 | 647 | - ICO 이후 공급량: (i) 하루 2,880개의 MET 또는 (ii) 연간 남은 공급량의 2.0000%(연율) 중 더 큰 수량에 해당하는 연간 공급량 648 | 649 | - 실시간으로 경매 결제 650 | 651 | - 일부 경제학자는 모두가 지정 가격을 지불하므로, 이 발견을 경매의 최적가로 제안하기도 함[^42] 652 | 653 | ### 공급표 654 | 655 | | 시간 | MET 유통량 | 조폐율 | 일일 조폐율 | 656 | |--|--|--|--| 657 | | T + 1년 | 11,051,200 | 10.512% | 2,880 | 658 | | T + 2년 | 12,102,400 | 9.512% | 2,880 | 659 | | T + 3년 | 13,153,600 | 8.686% | 2,880 | 660 | | T + 5년 | 15,258,880 | 7.399% | 2,880 | 661 | | T + 10년 | 20,517,760 | 5.400% | 2,880 | 662 | | T + 50년 | 63,499,700 | 2.000% | 3,411 | 663 | | T + 70년 | 94,382,561 | 2.000% | 5,070 | 664 | 665 | *표 2: 공급표* 666 | 667 | 668 | **API 참조** 669 | 670 | 메트로놈 코어 671 | -------------- 672 | 673 | ### 토큰 API 674 | 675 | MET 토큰을 쿼리하고 이체하는 데 사용되는 토큰 API는 널리 알려진 ERC20 토큰 표준입니다.[^43] 그리고 메트로놈 역시 향상된 분산형 이체와 보안에서 최신 표준을 준수하기 위해 맞춤 기능을 활용합니다. 이러한 개선 사항으로 인해 이체를 쉽게 수행하여 계약 수신 시 모든 함수를 호출할 수 있습니다. 값 뿐만 아니라 데이터도 전송할 수 있도록 지원하며, 이는 ERC20 토큰 표준만으로는 수행할 수 없는 기능입니다. 메트로놈은 가장 최신 기술을 활용하고 있다는 자부심을 갖고 있습니다. 676 | 677 | **표준 ERC20** 678 | 679 | | const name | Metronome | 680 | |--|--| 681 | | const symbol | MET | 682 | | const decimals | 18 | 683 | | function totalSupply | ERC20 부합. ERC20 표준 참조. | 684 | | function balanceOf | ERC20 부합. ERC20 표준 참조. | 685 | | function transfer | ERC20 부합. ERC20 표준 참조. | 686 | | function transferFrom | ERC20 부합. ERC20 표준 참조. | 687 | | function approve | ERC20 부합. ERC20 표준 참조. | 688 | | function allowance | ERC20 부합. ERC20 표준 참조. | 689 | | event Transfer | ERC20 부합. ERC20 표준 참조. | 690 | | event Approval | ERC20 부합. ERC20 표준 참조. | 691 | 692 | 693 | **맞춤형 토큰 함수** 694 | 695 | 696 | 697 | 698 | 699 | 701 | 702 | 703 | 704 | 705 | 706 | 707 | 708 | 709 | 710 | 711 | 712 | 713 | 714 | 715 | 716 | 717 | 718 | 719 | 720 | 721 | 722 | 723 | 724 | 725 |
Function multiTransfer(uint[] bits)단일 거래에서 다중 이체를 수행합니다. 비트 어레이의 각 단위는 이체를 나타냅니다. 700 | 맨 왼쪽의 160비트는 주소이며, 오른쪽의 96비트는 금액입니다.
function setTokenPorter(address _tokenPorter) public onlyOwner returns (bool)내보내기 기능을 담당하는 TokenPorter에 대한 계약을 설정하며, 이는 소유자만 실행할 수 있습니다.
function mint(address _to, uint _value) public returns (bool)발행은 화폐 발행자 및 토큰포터만 수행할 수 있습니다.
function destroy(address _from, uint _value) public returns (bool)폐기는 화폐 발행자 및 토큰포터만 수행할 수 있습니다.
function enableMTNTransfers() public returns (bool)이 함수를 사용하면 MET 이체가 가능하며 이는 ICO 종료 후에만 성공적으로 호출할 수 있습니다.
function export(bytes8 _destChain, address _destMetronomeAddr, address _destRecipAddr, uint _amount, bytes _extraData) public returns (bool)MET를 다른 메트로놈 지원 체인에 내보냅니다.
726 | 727 | **머클** 728 | 729 | 다음 함수는 수동으로 사용되지 않으나, 흥미로운 UI 기능을 위한 730 | 기반으로 간주되기도 합니다. 731 | 732 | | Function setRoot(bytes32 root) | msg.sender와 관련된 머클 루트를 설정합니다. | 733 | | ------------------------------------------------------------------- | -------------------------------------------------------- | 734 | | Function rootsMatch(address a, address b) constant returns (bool) | 두 가지 주소에 일치하는 루트가 있을 경우 true를 반환합니다. | 735 | | function getRoot(address addr) public view returns (bytes32) | 주소와 관련된 머클 루트를 가져옵니다. | 736 | 737 | **구독** 738 | 739 | 다음 함수는 메트로놈의 고유한 기능 중 하나인 블록체인상의 구독 기능입니다. 사용자는 구독을 통해 다른 사용자와 기관 간의 관계 및 반복 결제를 740 | 원활하게 수행할 수 있습니다. 사용자는 주간 결제를 인출하도록 승인하여 구독을 신청합니다. 741 | 승인된 그룹 또는 개인은 사용자 계정에서 적합하다고 생각되는 계정으로 결제를 옮길 수 있습니다. 사용자는 필요한 경우 742 | 구독을 취소할 수 있습니다. 743 | 744 | 이는 과거 다른 가상화폐가 어려움을 겪어 온 문제를 해결합니다. 많은 종류의 유명한 가상화폐가 존재하는 상황에서 745 | 자료를 기반으로 구독 비용을 지불하는 것은 불가능하거나 매우 어려운 일입니다. 메트로놈 구독 기능은 이를 해결합니다. 746 | 747 | 748 | 749 | 750 | 751 | 752 | 753 | 754 | 755 | 756 | 757 | 758 | 759 | 760 | 761 | 762 | 764 | 765 | 766 | 767 | 768 | 769 | 770 | 771 | 772 | 773 | 774 | 775 | 776 | 777 | 778 | 779 | 780 | 781 | 782 |
function subscribe(uint _startTime, uint _payPerWeek, address _recipient) public returns (bool)다른 사용자 구독(예: 주간 결제를 인출하도록 승인). payment _startTime은 구독 시작 시간이고, _payPerWeek는 주당 지불 가능한 토큰이며(소수점 포함), _recipient는 인출할 토큰을 받는 대상입니다.
function cancelSubscription(address _recipient) public returns (bool)구독 취소. _recipient는 구독을 취소할 대상입니다.
function getSubscription(address _owner, address _recipient) public constant returns (uint startTime, uint payPerWeek, uint lastWithdrawTime)구독 정보 받기. _owner는 지불하는 사람이며, _recipient는 구독을 받는 사람입니다. 다음 정보 반환. startTime은 구독을 시작하는 시간입니다. payPerWeek는 매주 수신자가 인출할 수 있는 수량입니다. lastWithdrawTime은 수신자가 마지막으로 인출한 시간입니다.
function subWithdraw(address _owner) public transferable returns (bool)귀하를 구독한 사용자의 자금을 인출하며, 성공 시 반환됩니다. 763 | _owner는 귀하의 구독자입니다.
function multiSubWithdraw(address[] _owners) public returns (uint)여러 구독자(_owners)의 자금을 한 번에 인출합니다. 인출 성공 횟수를 반환합니다.
function multiSubWithdrawFor(address[] _owners, address[] _recipients) public returns (uint)지정된 구독자(_owners)의 자금을 해당 _recipients에게 인출합니다. 인출 성공 횟수를 반환합니다.
event LogSubscription(address indexed subscriber, address indexed subscribesTo)새로운 사용자 구독을 내보냅니다.
event LogCancelSubscription(address indexed subscriber, address indexed subscribesTo)사용자가 구독을 취소할 경우 내보냅니다.
783 | 784 | ### 경매 API 785 | 786 | 787 | 788 | 789 | 790 | 791 | 792 | 793 | 794 | 795 | 796 | 797 | 798 | 799 | 800 | 801 | 802 | 803 | 804 | 805 | 806 | 807 | 808 | 809 | 810 | 811 | 812 | 813 | 814 | 815 | 816 | 817 | 818 | 819 | 820 | 821 | 822 | 823 | 824 | 825 | 826 | 827 | 828 | 829 | 830 | 831 | 832 | 833 | 834 | 835 | 836 | 837 | 838 | 839 | 840 | 841 | 842 | 843 | 844 | 845 | 846 | 847 | 848 | 849 | 850 | 851 | 852 | 853 | 854 | 855 |
Function () payable표준 폴백 함수. ETH를 전송하고 MET 토큰을 즉시 수신합니다.
function whatWouldPurchaseDo(uint _wei, uint _timestamp) public constant returns (uint weiPerToken, uint tokens, uint refund)구매 시 사용자에게 예상 결과를 알립니다. _timestamp _wei는 wei에서 전송할 ETH의 수량이고, _timestamp는 향후 경매 구매의 타임스탬프입니다. weiPerToken은 결과 가격이고, tokens는 반환될 토큰의 개수이며, refund는 사용자가 wei 단위로 받게 될 ETH 환불입니다(본 구매 시 경매가 매진된 경우).
function isRunning() public constant returns (bool)경매 시스템이 시작된 경우 True입니다.
function currentTick() public view returns(uint)현재 블록 타임스탬프에 대한 whichTick을 호출합니다.
function currentAuction() public view returns(uint)whichAuction(currentTick())을 호출합니다.
function whichTick(uint t) public view returns(uint)최초 시간 이후의 지정된 타임스탬프에 대한 경매 표시 t를 반환합니다.
function whichAuction(uint t) public view returns(uint)지정된 경매 표시 t에 대한 경매 인스턴스를 반환합니다.
function heartbeat() public view returns (bytes8 chain,address auctionAddr,address convertAddr,address tokenAddr,uint minting,uint totalMet,uint proceedsBal,uint currTick, uint currAuction,uint nextAuctionGMT,uint genesisGMT,uint currentAuctionPrice,uint dailyMintable,uint _lastPurchasePrice)현재 경매에 대한 통계를 반환합니다.
function mintInitialSupply(uint[] _founders, address _token, address _proceeds, address _autonomousConverter) public onlyOwner returns (bool)설립자에 대한 초기 공급량을 발행하기 위해 초기 개발 기간에 호출됩니다. 이는 소유자 전용 함수입니다.
function initAuctions(uint _startTime, uint _minimumPrice, uint _startingPrice, uint _timeScale) public onlyOwner returns (bool)경매 시작 시간 매개변수를 설정하는 초기 개발 기간에 호출됩니다. 이는 소유자 전용 함수입니다.
function stopEverything() public onlyOwner현재 경매를 일시 중지하는 소유자 전용 함수입니다.
function isInitialAuctionEnded() public view returns (bool)7일이 경과하거나 초기 경매에서 토큰 전량이 매진된 경우 True입니다.
function globalMetSupply() public view returns (uint)현재 경매를 기준으로 총 사용 가능한 공급량입니다.
function globalDailySupply() public view returns (uint)현재 일일 경매의 총 사용 가능한 MET 토큰입니다.
function currentPrice() public constant returns (uint weiPerToken)일일 경매의 현재 가격입니다.
event LogAuctionFundsIn(uint amount)경매 계약에 의해 자금이 전달되면 내보냅니다.
856 | 857 | 메트로놈 수익금 계약 858 | --------------------------- 859 | 860 | ### 수익금 계약 API 861 | 862 | | event LogProceedsIn(address indexed from, uint value) | 수익금 계약에 의해 자금이 전달되면 내보냅니다. | 863 | | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------- | 864 | | event LogClosedAuction(address indexed from, uint value) | 수익금에서 자금을 AutonomousConverter에 푸시하면 내보냅니다. | 865 | | function () public payable | 수익금에 대한 유입 자금을 처리합니다. | 866 | | function initProceeds(address \_autonomousConverter, address \_auction) public onlyOwner | 초기 개발 과정에서 호출됩니다. 이는 소유자 전용 함수입니다. | 867 | | function closeAuction() public | 경매 종료 시 자금을 AutonomousConverter에 전송합니다. | 868 | 869 | 메트로놈 자율환산계약 870 | --------------------------------------- 871 | 872 | ### 자율환산계약 API 873 | 874 | 875 | 876 | 877 | 878 | 879 | 880 | 881 | 882 | 883 | 884 | 885 | 886 | 887 | 888 | 889 | 890 | 891 | 892 | 893 | 894 | 895 | 896 | 899 | 900 | 901 | 902 | 905 | 906 | 907 | 908 | 910 | 911 | 912 | 913 | 915 | 916 | 917 | 918 | 919 | 920 | 921 | 922 | 923 | 924 | 925 | 926 | 927 | 928 | 929 |
function () public payableAutonomousConverter에 유입되는 자금을 처리합니다.
function init(address _reserveToken, address _smartToken, address _proceeds, address _auctions) public payable초기 개발 과정에서 호출됩니다. 이는 소유자 전용 함수입니다.
function getMetBalance() public view returns (uint)계약의 MET 잔액을 표시합니다.
function getEthBalance() public view returns (uint)계약의 ETH 잔액을 표시합니다.
function convertEthToMet(uint _mintReturn) public payable returns (uint returnedMet)ETH를 MET로 변경합니다. 반환된 MET가 897 | minReturn보다 작을 경우 발생합니다. MET의 수량을 898 | 반환합니다.
function convertMetToEth(uint _amount, uint _mintReturn) public returns (uint returnedEth)MET를 ETH로 변경합니다. 반환된 ETH가 903 | minReturn보다 작을 경우 발생합니다. ETH의 수량을 반환합니다. 호출자는 우선 AC를 승인하여 이체를 수행해야 904 | 합니다.
function getMetForEthResult(uint _depositAmount) public view returns (uint256)지정된 _depositAmount에 대해 909 | 사용자가 MET 단위로 받게 될 ETH 수량을 반환합니다.
function getEthForMetResult(uint _depositAmount) public view returns (uint256)지정된 _depositAmount에 대해 914 | 사용자가 ETH 단위로 받게 될 MET 수량을 반환합니다.
event LogFundsIn(address indexed from, uint value)AutonomousConvert에 자금이 전송되면 내보냅니다.
event ConvertEthToMet(address indexed from, uint eth, uint met)ETH에서 MET로 전환할 경우 내보냅니다.
event ConvertMetToEth(address indexed from, uint eth, uint met)MET에서 ETH로 전환할 경우 내보냅니다.
930 | 931 | TokenLocker 932 | ----------- 933 | 934 | ### TokenLocker API 935 | 936 | | event Withdrawn(address indexed who, uint amount) | 모든 인출 시 내보냅니다. | 937 | | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | 938 | | event Deposited(address indexed who, uint amount) | 모든 예치 시 내보냅니다. | 939 | | function lockTokenLocker() public onlyAuction | tokenLocker를 잠급니다. 이 함수를 호출하면 tokenLocker가 postLock 단계가 됩니다. 더 이상 예치를 할 수 없습니다. 이 단계에서는 토큰 인출이 가능합니다. 이는 경매 전용 함수입니다. | 940 | | function deposit (address beneficiary, uint amount) public onlyAuction preLock | 자금을 로커에 예치합니다. 자금 예치는 preLock 단계에서만 허용됩니다. | 941 | | function withdraw() public onlyOwner postLock | 자금 인출은 postLock 단계에서만 허용됩니다. 이는 소유자 전용 함수입니다. | 942 | 943 | TokenPorter 944 | ----------- 945 | 946 | ### TokenPorter API 947 | 948 | | event ExportReceiptLog(bytes8 destinationChain, address indexed destinationMetronomeAddr, address indexed destinationRecipientAddr, uint amountToBurn, bytes extraData, uint currentTick, uint indexed burnSequence, bytes32 currentBurnHash, bytes32 prevBurnHash, uint dailyMintable, uint\[\] supplyOnAllChains, uint genesisTime) | 내보내기 요청 시 내보냅니다. | 949 | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | 950 | | function addDestinationChain(bytes8 \_chainName, address \_contractAddress) public onlyOwner returns (bool) | 메트로놈 내보내기를 위해 승인된 체인으로 체인을 추가합니다. 이는 소유자 전용 함수입니다. | 951 | | function removeDestinationChain(bytes8 \_chainName) public onlyOwner returns (bool) | 메트로놈 내보내기를 위해 승인된 체인에서 체인을 제거합니다. 이는 소유자 전용 함수입니다. | 952 | | function claimReceivables(address\[\] recipients) public returns (uint) | 이 함수는 대상 계약에서 메트로놈 발행량을 기록하기 위해 메트로놈 가져오기를 수행하려는 대상 계약에 의해 호출됩니다. | 953 | | function export(bytes8 \_destChain, address \_destMetronomeAddr, address \_destRecipAddr, uint \_amount, bytes \_extraData) public returns (bool) | 가져올 사용자 계정을 다른 체인으로 내보냅니다. | 954 | 955 | 계약 약관 용어 956 | ========================== 957 | 958 | - **자율환산계약(Autonomous Converter Contract)** - 사용자가 MET를 ETH로 또는 ETH를 MET로 교환할 수 있도록 지원하는 스마트 계약입니다. 959 | 960 | - **자율 수익금 제공자(Autonomous Proceeds Provider)** - 메트로놈 수익금 계약 및 자율환산계약입니다. 961 | 962 | - **상수** - 몇 가지 공통 상수를 보유합니다(예: 소수점). 963 | 964 | - **일일 공급량** - 새로 발행된 MET를 매일 생태계에 추가하는 내림 경매 방식입니다. 965 | 966 | - **EVM** - Ethereum Virtual Machine의 약어입니다.[^44] 967 | 968 | - **Fixed\_Math** - 덧셈, 뺄셈, 곱셈, 나눗셈, 제곱근을 비롯한 고정 소수점 연산을 구현합니다. 여기에는 오버플로 방지가 포함됩니다. 바이너리 함수의 경우, 두 입력값에 동일한 개수의 소수점이 포함된 것으로 간주합니다. 969 | 970 | - **공식** - 고정 수학 함수를 사용하여 핵심 Bancor 스타일 공식을 구현합니다. 공식은 상태를 저장하지 않으며 모든 변수는 매개변수로 전달됩니다. 971 | 972 | - **메트로놈** - 주요 경매 계약입니다. 973 | 974 | - **마이그레이션** - Truffle의 마이그레이션 기능 중 일부입니다. 975 | 976 | - **ReserveToken** - MET를 구현합니다. 거래 이벤트에 대한 응답으로, 자율환산계약이 토큰을 이동할 수 있는 권한을 제공합니다. 977 | 978 | - **수익금 계약** - 메트로놈의 ETH를 승인하고, 잔액의 0.25%를 24시간마다 자율환산계약에 전달합니다. 979 | 980 | - **스마트 토큰** - 자율환산계약에서 발행되는 토큰으로, 자율환산계약을 통해 MET를 ETH로 변경할 경우(또는 그 반대) 중개자 역할을 합니다. 이 프로세스는 자동화되어 있으며 사용자에게 공개되지 않습니다. 981 | 982 | - **토큰** - 구매자가 구매하는 MET 토큰입니다. 983 | 984 | 부록 A 985 | ========== 986 | 987 | 동의 및 고지 사항 988 | 989 | 메트로놈 토큰을 구매, 소유 및/또는 사용할 경우 귀하는 다음과 같은 위험에 동의하고 가정합니다. 990 | 991 | 1. **[구매자 동의]**. 메트로놈 토큰("MET")의 구매자("구매자" 또는 "귀하")로서, 귀하는 다음 사항을 인정하게 됩니다. 992 | 993 | a. MET는 [not]구조화되어 있거나, 증권으로 판매되거나, 994 | 기타 형태로 된 투자 상품입니다. MET는 1933년 995 | 증권법(수정본 기준)이나 주 증권법 또는 기타 재판관할권의 모든 996 | 유사한 법률에 의거하여 미국 증권거래위원회에 등록되어 있지 997 | 않으며, 이러한 법률에 따른 면제 조항에 의거하여 기능하지 998 | 않습니다. 따라서, 본 소유자 설명서에 제시된 정보는 999 | 투자 결정의 기준이 되지 않으며 특정 사항을 의도적으로 1000 | 권장하지 않습니다. 1001 | MET의 사용, 판매 또는 기타 파기는 소유자 설명서에 1002 | 명시된 대로 제한됩니다. MET를 구매한 구매자는 소유자 설명서의 모든 요구사항 및 모든 재판관할권에서 공포된 모든 1003 | 법률(미국 연방법, 주법 또는 현지법 포함)을 준수하는 것으로 1004 | 간주됩니다. MET 개발자는 (i) 소유자 설명서 또는 기타 문서에 1005 | 포함된 정보에 대한 신뢰, (ii) 이러한 정보의 오류, 누락 또는 1006 | 부정확성, (iii) 이러한 정보로 인한 조치로 인해 직간접적으로 1007 | 발생하는 모든 종류의 직접적 또는 결과적 손실이나 손해에 대한 1008 | 모든 책임을 명시적으로 부인합니다. 1009 | 1010 | 1011 | 1012 | 1013 | 1014 | 1015 | b. 본 문서는 Monetary Authority of Singapore의 사업설명서로 1016 | 등록된 바가 없고 향후에도 등록될 예정이 없으며, 싱가포르 증권 및 1017 | 선물법(289장)("**SFA**")에 정의된 바와 같은 1018 | 사업설명서가 아닙니다. 따라서 사업설명서의 내용과 관련하여 SFA에 따른 1019 | 법적 책임이 1020 | 적용되지 않습니다. 1021 | 1022 | c. 귀하는 MET 즉, 메트로놈을 사용하여 미국 1023 | 상품선물거래위원회에서 규제하는 상품을 만들 수 없으며, 1024 | 여기에는 선물 계약, 스왑 또는 소매 상품 거래가 포함됩니다. 1025 | 또한, 귀하는 MET 구매가 모든 형태의 옵션 또는 스왑 거래를 목적으로 1026 | 하지 않으며 이러한 거래로서 마케팅되지 않는다는 것을 1027 | 인정합니다. 1028 | 1029 | d. 귀하는 MET를 이해하고 MET의 사용, 구매 및/또는 파기에 따른 1030 | 위험과 영향력을 인지하는 데 필요한 암호화 토큰, 토큰 저장 1031 | 메커니즘(예: 토큰 지갑), 블록체인 기술과 관련된 1032 | 기술적 및 사업적 문제를 이해합니다. 1033 | 1034 | 1035 | e. 귀하는 MET 구매 시 정보에 입각한 결정을 내릴 수 있도록 1036 | MET에 대한 충분한 정보를 습득했으며, MET 구매 결정 시 1037 | 본 소유자 설명서에 제공된 것 이외의 다른 정보를 신뢰하지 1038 | 않습니다. 1039 | 1040 | f. 귀하는 MET가 소유자 설명서에서 고찰한 방식대로만 MET를 1041 | 사용할 수 있는 권한을 부여한다는 점을 숙지합니다. MET는 다른 형태의 권한을 1042 | 부여하지 않으며 여기에는 회사 소유권, 배포, 청산, 1043 | 독점적(모든 형태의 지적 재산권 포함), 재정적 또는 법적 1044 | 권한을 포함하되 이에 국한되지 않는다는 1045 | 사실을 숙지합니다. 1046 | 1047 | g. 귀하는 소유자 설명서에서 고찰한 방식대로 MET를 사용하기 위한 1048 | 목적으로만 MET를 구매하며, MET와 관련된 상업적 위험을 1049 | 인지하고 있습니다. 귀하는 다른 목적으로 MET를 구매하지 않으며 1050 | 여기에는 투자, 투기 또는 금융적 목적을 포함하되 이에 국한되지 1051 | 않습니다. 1052 | 1053 | h. 귀하의 MET 구매는 해당 재판관할권의 준거법과 규정을 1054 | 준수하며 여기에는 (i) MET 구매에 대한 행위 능력과 요구 사항 1055 | 또는 제한, (ii) 이러한 구매에 적용되는 외환 또는 규제 제한, 1056 | (iii) 정부 기관의 동의 또는 필요 시 얻어야 하는 그밖의 동의를 1057 | 포함하되 이에 국한되지 않습니다. 1058 | 1059 | 1060 | i. 귀하는 MET의 구매 또는 사용으로 인해 발생하는 1061 | 모든 납세의 의무에 대해 전적인 책임이 있습니다. 1062 | 1063 | j. 귀하가 회사를 대표하여 MET를 구매할 경우, 귀하에게는 1064 | 해당 회사를 대신하여 이러한 동의 및 고지 사항에 동의할 수 있는 권한이 1065 | 부여됩니다. 1066 | 1067 | k. 귀하는 (i) 준거법, 법령, 규정, 조약 또는 행정법에 따라 MET의 1068 | 인도 승인이 금지된 지역의 시민이나 거주자가 아니며, (ii) 국제연합, 유럽연합, 미국 1069 | 또는 다른 주권 국가의 제재나 엠바고가 적용되는 지역의 1070 | 시민이나 거주자가 아니며, (iii) 미국 상무부의 무역 금지 대상/회사 목록, 1071 | 미국 재무부의 특별 제재 국가/제재 인물 목록, 미국 1072 | 국무부의 금지 대상 목록, 기타 해당 주권 국가의 유사한 제재 인물 규제나 1073 | 목록, 또는 전술한 항목의 후속 규제나 제재에 오른 회사에 고용되어 1074 | 있거나 관련이 있는 당사자가 아닙니다. 귀하는 현재 거주 국가 1075 | 또는 그밖의 상황이 변경되어 위에서 동의한 사항이 더 이상 1076 | 정확성을 보장하지 않게 될 경우, MET 사용을 즉시 1077 | 중단하는 데 동의합니다. 1078 | 1079 | 1080 | 1081 | 1082 | 1083 | l. MET의 가치는 가상화폐로서 인정되는지 여부와 상품 및 1084 | 서비스 결제에 활용되는 범위에 따라 달라집니다. 수요가 1085 | 충분하지 않으면 상품 및 서비스 결제에 MET를 활용하기 어려울 수 있으며, 1086 | 이 경우 MET의 가치가 하락하게 됩니다. 마찬가지로, MET가 1087 | 널리 보급되지 않을 경우에도 가치가 하락할 수 있습니다. 1088 | 그뿐만 아니라, 단기적으로 보았을 때 가상화폐 및 토큰 판매의 1089 | 감독과 관련하여 상당한 규제 위험이 여전히 존재하며 1090 | 이는 MET의 가치를 크게 떨어뜨릴 수 있습니다. 1091 | 1092 | 1093 | m. MET의 가치는 상품 및 서비스 결제에 MET를 가상화폐로서 사용할 때의 1094 | 가치에 따라 주로 결정됩니다. 1095 | 1096 | 1097 | n. MET의 가격은 가상화폐로서 MET의 일반적인 수요와 공급에 영향을 1098 | 미치는 경쟁 조건과 시장 조건에 대응하여 변동됩니다. 이러한 1099 | 조건은 특정 당사자나 MET 보유자의 통제 범위 밖입니다. MET를 1100 | 사용하거나 교환할 때의 가치는 처음에 구매했을 때의 1101 | 가격보다 낮아질 수 있습니다. 1102 | 1103 | 1104 | o. 규칙적이고 자동화된 독립적 방식으로 새로운 MET를 발행하는 목적은 1105 | 메트로놈 생태계 내에서 서비스에 대한 MET의 본질적 가치와 1106 | 관련하여 MET의 가격을 안정화시키는 데 일조하기 위해서입니다. 그러나 1107 | 이러한 MET 발행이 반드시 성공하리라고 보장할 수는 없습니다. 자신의 목적에 따라 어떤 1108 | 가격으로든 MET를 매매할 수 있습니다. 1109 | 1110 | p. MET를 판매한다고 해서 메트로놈 개발자가 다른 프로젝트에 참여하거나, 다른 1111 | 네트워크를 운영하거나, MET의 경쟁상대가 될 수 있는 다른 토큰을 1112 | 발행하는 권한이 제한되지는 않습니다. 1113 | 1114 | q. 본질적 가치의 보장, 지속적 지불에 대한 보장을 비롯하여 MET와 1115 | 관련된 미래의 성과나 가치를 보장할 수 없으며, MET가 특정한 가치를 1116 | 보유하게 될 것이라고 보증할 수 없습니다. 1117 | 1118 | 1119 | r. 메트로놈 개발자가 자신의 MET 판매를 통해 얻은 수익금을 사용할 수 있는 1120 | 방법에 대한 조건은 없습니다. 1121 | 1122 | 2. **[특정 위험에 대한 동의]**. 귀하는 MET에 다음과 같은 1123 | 위험이 있다는 점을 인정하며 이러한 위험을 명시적으로 1124 | 가정하고 있다는 데 동의합니다. 1125 | 1126 | s. ***MET의 자율적 특성***. MET는 MET의 운영에 영향력을 1127 | 가하거나 통제하는 당사자의 기능 없이 자율적으로 운영됩니다. 1128 | MET의 자율적 특성은 MET 출시 당시 또는 구매 당시에는 1129 | 예측할 수 없었던 위험을 비롯하여, 향후 여러 위험을 야기할 수 있습니다. 1130 | 1131 | 1132 | t. ***프라이빗 키 분실, 관리 실수 또는 구매 실수로 인한 MET 액세스 1133 | 권한 손실 위험.*** 프라이빗 키 또는 프라이빗 키 조합은 1134 | 디지털 지갑이나 자격 증명 모음에 저장된 MET를 제어하고 1135 | 파기하는 데 필요합니다. 따라서, MET를 저장하는 디지털 지갑 또는 1136 | 자격 증명 모음과 관련된 필수 프라이빗 키를 분실할 경우, 1137 | 이러한 MET를 잃어버리게 됩니다. 그뿐만 아니라, 이러한 프라이빗 1138 | 키에 대한 액세스 권한을 획득(예: 사용 중인 호스팅 지갑 1139 | 서비스의 로그인 자격 증명에 대한 액세스 권한 획득)할 경우 1140 | 제3자가 MET를 가로챌 수 있습니다. 이러한 디지털 지갑 또는 1141 | 자격 증명 모음을 올바르게 유지하거나 사용하지 못하는 경우를 1142 | 포함하여, MET를 전송받고 저장하기로 선택한 디지털 지갑 또는 1143 | 자격 증명 모음과 관련된 오류 또는 오작동이 발생할 경우에도 1144 | MET가 손실될 수 있습니다. 또한, MET 구매와 전송에 대해 1145 | 규정된 절차를 정확히 따르지 않을 경우(예: 잘못된 주소 제공)에도 1146 | MET가 손실될 수 있습니다. 1147 | 1148 | 1149 | u. ***블록체인 프로토콜과 관련된 위험.*** MET가 운영되는 1150 | 블록체인 프로토콜의 오작동, 고장 또는 중단은 MET에 실질적인 1151 | 악영향을 미칠 수 있습니다. 그리고 암호학 또는 기술이 발전하게 되면 1152 | 블록체인 프로토콜을 뒷받침하는 암호화 합의 메커니즘의 효과를 1153 | 무력화하여 MET에 위험을 야기할 수 있습니다. 1154 | 1155 | 1156 | 1157 | v. ***채굴 공격 위험.*** MET는 블록체인에서 MET 거래를 검증하는 1158 | 과정에서 채굴자들의 공격을 받기 쉽습니다. 이러한 1159 | 공격에는 이중 사용 공격, 다수의 채굴 파워 공격, 선택적 지연 또는 1160 | 거래 검열, 자체 채굴 공격을 포함하되 이에 국한되지 않습니다. 공격이 1161 | 성공하면 MET에 위험을 야기하며, 여기에는 MET와 관련된 1162 | 거래의 정확한 실행 및 기록을 포함하되 이에 국한되지 않습니다. 1163 | 1164 | 1165 | w. ***해킹 및 보안 약점의 위험.*** 해커 또는 기타 악의적인 단체나 1166 | 조직은 다양한 방법으로 MET에 간섭하려고 시도할 수 있으며 1167 | 여기에는 멀웨어 공격, 서비스 거부 공격, 합의 기반 공격, Sybil 공격, 1168 | 스머핑 및 스푸핑을 포함하되 이에 국한되지 않습니다. 게다가 MET는 1169 | 오픈소스 소프트웨어 기반이므로 제3자가 새로운 MET 구현의 1170 | 코어 인프라에 의도적으로 또는 무심결에 약점을 유입시킬 1171 | 위험이 있으며, 이는 MET에 부정적인 영향을 미칠 수 있습니다. 해커 또는 1172 | 기타 악의적인 단체나 조직은 MET를 전송받고 보유하는 데 사용되는 지갑, 1173 | 자격 증명 모음이나 기타 저장소 내의 프라이빗 키 또는 자격 증명에 1174 | 대한 액세스 권한을 얻으려는 시도를 할 수도 있습니다. 1175 | 1176 | 1177 | 1178 | x. ***MET 시장과 관련된 위험.*** 제3의 거래소에서 이차적인 1179 | MET 거래를 진행할 경우, 이러한 거래소는 비교적 신생 업체이고 1180 | 규제 감독이 거의 시행된 적이 없을 가능성이 있으므로 1181 | 사기나 조작에 연루되기 쉽습니다. 또한, 제3자가 외부적인 교환 1182 | 가치가 MET로 인한 것이라고 간주하는 한(예: 디지털 화폐 또는 명목화폐로 1183 | 액수를 매긴 경우), 이러한 가치는 극도로 불안정하며 휴지 조각이 될 수 있습니다. 1184 | 1185 | 1186 | 1187 | y. ***보험이 적용되지 않는 손실의 위험.*** 특정 은행 계좌나 다른 1188 | 금융 기관의 계좌와 달리, MET는 보험이 적용되지 않습니다. 따라서 1189 | 손실이 발생하거나 실용 가치가 사라질 경우 상환 청구를 제공할 수 있는 1190 | 공공 보험사나 민간 보험이 없습니다. 1191 | 1192 | z. ***불확실한 규제 및 시행 조치와 관련된 1193 | 위험.*** 대다수의 재판관할권에서 MET 및 분산 원장 기술의 규제 현황은 불확실하고 1194 | 안정적이지 않습니다. 규제 당국이 MET 같은 이러한 기술과 애플리케이션에 1195 | 기존의 규제를 어떤 방식으로 적용할지 또는 적용할 것인지 여부를 1196 | 예측하기란 어렵습니다. 이와 마찬가지로, 국회나 규제 당국이 MET 1197 | 같은 분산 원장 기술과 애플리케이션에 영향을 미치는 1198 | 법과 규제의 변경을 어떻게 적용할지 또는 적용할 것인지 1199 | 여부를 예측하는 일 또한 어렵습니다. 규제 조치는 여러 방식으로 1200 | MET에 부정적인 영향을 미칠 수 있습니다. 설명을 위해 예를 들자면 1201 | MET의 구매, 판매, 제공을 불법적 행위로 간주하는 결정, 혹은 MET를 1202 | 규제 대상 수단으로 보고 이러한 수단이나 MET의 구매, 판매, 1203 | 제공과 연루된 일부 또는 모든 당사자를 등록하고 라이선스를 1204 | 교부하는 절차가 필요하다고 보는 결정이 이러한 규제 조치에 1205 | 해당합니다. 1206 | 1207 | 1208 | 1209 | a. ***세금 부과로 인한 위험.*** MET의 세금 특성은 불확실하며 원천세, 1210 | 소득세, 세금 신고 요건을 비롯하여 불리한 납세 결과를 초래할 수 1211 | 있습니다. MET와 관련된 세금에 대해 자문을 구해야 합니다. 1212 | 1213 | 1214 | 1215 | b. ***기술 위험.*** MET는 아직 완전히 검증되지 않은 채 1216 | 사용 중인 신흥 기술의 새로운 기능을 상징합니다. 기술이 발전할수록 1217 | 새로운 기술의 등장으로 인해 MET의 효용성이나 MET의 사용 또는 1218 | 매도 기능이 크게 변동될 수 있습니다. 1219 | 1220 | c. ***예상치 못한 위험.*** 이 부록에서 다룬 위험 외에도 1221 | MET의 구매, 소유, 사용과 관련하여 예상치 못한 위험을 비롯한 1222 | 여타 위험 요소가 존재합니다. 이러한 위험은 예상치 못한 변수나 이 부록에서 1223 | 살펴본 여러 위험이 한꺼번에 나타날 때 더욱 구체적으로 나타날 수 1224 | 있습니다. 1225 | 1226 | 1227 | 1228 | 1229 | 1. **[부인]**. 각 MET는 어떤 주체가 제공하는 일체의 보증이 없이 "있는 그대로", 그리고 "사용 가능한 대로" 판매되며 이러한 보증에는 상품성, 특정 목적에 대한 적합성, 소유권 또는 비침해에 대한 묵시적 보증을 포함하되 이에 국한되지 않습니다. 1230 | 1231 | [^1]: 1232 | 1233 | [^2]: 1234 | 1235 | [^3]: 1236 | 1237 | [^4]: 1238 | 1239 | [^5]: 1240 | 1241 | [^6]: 1242 | 1243 | [^7]: Tsiang, S.C., Journal of Money, Credit and Banking, I(1969), pp. 1244 | 266--80 \"A Critical Note on the Optimum Supply of Money\" 1245 | 1246 | [^8]: 1247 | 1248 | [^9]: 1249 | 1250 | [^10]: 1251 | 1252 | [^11]: 1253 | 1254 | [^12]: 1255 | 1256 | [^13]: 1257 | 1258 | [^14]: 1259 | 1260 | [^15]: 출처: coinmarketcap, coinbase, blockchain.info, Federal Reserve Bank of St Louis 1261 | 1262 | [^16]: 1263 | 1264 | [^17]: Mishra, Debasis, and David C. Parkes. "Multi-Item Vickrey-Dutch 1265 | Auctions." Games and Economic Behavior, vol. 66, no. 1, 2009, pp. 1266 | 326--347., doi:10.1016/j.geb.2008.04.007. 1267 | 1268 | [^18]: 1269 | 1270 | [^19]: 출처: coinmarketcap.com, coinbase, blockchain.info 1271 | 1272 | [^20]: 1273 | 1274 | [^21]: 1275 | 1276 | [^22]: 1277 | 1278 | [^23]: 1279 | 1280 | [^24]: 출처: coinmarketcap.com, coinbase, blockchain.info 1281 | 1282 | [^25]: 1283 | 1284 | [^26]: 1285 | 1286 | [^27]: 1287 | 1288 | [^28]: 1289 | 1290 | [^29]: 1291 | 1292 | [^30]: 1293 | 1294 | [^31]: 1295 | 1296 | [^32]: 1297 | 1298 | [^33]: 1299 | 1300 | [^34]: 1301 | 1302 | [^35]: 1303 | 1304 | [^36]: 1305 | 1306 | [^37]: 1307 | 1308 | [^38]: 1309 | 1310 | [^39]: 1311 | 1312 | [^40]: 1313 | 1314 | [^41]: 1315 | 1316 | [^42]: 1317 | 1318 | [^43]: 1319 | 1320 | [^44]: 1321 | 1322 | -------------------------------------------------------------------------------- /owners_manual/owners_manual_zh_CN.md: -------------------------------------------------------------------------------- 1 | ![Metronome](img/logo.png) 2 | 3 | 版本 0.986（上次更新时间 2018 年 5 月 30 日） 4 | 5 | **注释：** 6 | 7 | \(1) 本用户手册介绍一种新型加密货币 Metronome 的设计和结构，草稿仍在持续更新中。Metronome 及其基础技术仍处于开发阶段，本用户手册将在整个过程中更新以反映整个开发周期的变化。为了确保材料的准确性，已采取各种措施，但 Metronome 创始人及其合作伙伴不保证本用户手册中材料的准确性或完整性。 8 | 9 | \(2) Metronome 的潜在买方和 Metronome 生态系统的参与者应阅读本用户手册，其中包括附录 \[A\] 中的确认和免责声明，并且在购买之前应仔细考虑所有风险。 10 | 11 | **用户手册许可** 12 | 13 | © 2018 Autonomous Software 版权所有。保留未经许可方 14 | 明确授予的所有权利。 15 | 16 | AUTONOMOUS SOFTWARE（“许可方”）拥有并保留本“Metronome 用户手册”（以下简称“用户手册”）和通用版本（定义如下）的排他性所有权，以及全部权利、所有权、全部版权和其他知识产权。用户手册和通用版本统称为“工作”。 17 | 18 | “METRONOME”、“MET”和 METRONOME 徽标（统称为“METRONOME 标志”）是许可方的商标，仅在许可方明确书面许可的情况下才能使用。您不得在任何产品或服务上或以任何其他方式使用 METRONOME 标志或任何类似标志，这可能在市场上导致混淆，包括在广告中或在软件及硬件中。 19 | 20 | 1. **许可授予和限制。**根据本许可协议的条款和 21 | 条件，许可方在此授予您全球范围的、 22 | 免版税、非独占、永久许可，以复制、展示和 23 | 发行整个用户手册（不允许部分发行），不得 24 | 修改、调整或创建通用的衍生 25 | 版本（定义如下），以及复制、展示和发行此类作品； 26 | 前提条件是上述内容均不能暗示您 27 | 或您的工作或加密货币、智能合约或 28 | 技术与许可方或其附属机构有任何方式的关联或 29 | 认可。上述权利可在 30 | 所有媒体和形式中行使，无论是现在已知的还是此后 31 | 设计出来的。上述权利包括进行技术上必要的 32 | 修改以便 33 | 其他媒体和形式行使权利。每次您发行或公开 34 | 执行工作时，许可方都会按照与本许可中授予 35 | 您的许可，以相同的条款和条件向 36 | 工作授予工作许可。“通用版本”是指不包括或包含任何 37 | 许可方、许可方附属公司或 Metronome、MET 38 | 或任何 Metronome 标志的 39 | 用户手册版本。 40 | 41 | 2. **对用户手册的建议修改。**向用户手册提交任何 42 | 修改建议，即表明您同意向 43 | 许可方授予所提建议的所有版权，但不限于此类 44 | 修改。因此，许可方可以自行决定 45 | 在 46 | 用户手册（全部或部分，以及修改或未修改的 47 | 格式）中是否包括任何此类建议修改。 48 | 49 | 3. **声明和保证**。用户手册乃按原样提供，如无任何种类、明示、暗示、法定或其他任何形式的声明或保证，包括但不限于对所有权、适销性、特定用途适用性、非侵权性、准确性，或是否存在错误的保证。某些司法管辖区不允许排除暗示性的保证，因此这些排除条款可能不适用于您。 50 | 51 | 4. **可执行性**。如果本许可的某项条款无效或在适用法律下无法执行，本许可其余条款的有效性或可执行性不受影响，若本协议双方未采取进一步行动，则应将此条款更改为使此类条款有效且可强制执行所必需的最低限度。本许可的任何条款均不得被视为放弃，也不应被视为同意，否则此类放弃或同意应以书面形式签署，并由负责放弃或同意的一方签署。 52 | 53 | 5. **条约权利**。本许可中所授予的权利以及所引用的主题基于《保护文学和艺术作品伯尔尼公约》（1979 年 9 月 28 日修订）、1961 年《罗马公约》、1996 年《WIPO 版权条约》、1996 年《世界知识产权组织表演和录音制品条约》和《世界版权公约》（1971 年 7 月 24 日修订）。这些权利和主题在相关的司法管辖范围内生效，根据适用的国家/地区法律中有关条约规定的相应条款，要求执行许可条款。如果在适用的版权法中授予的标准权利组别包括本许可下未授予的额外权利，则该等附加权利被视为在许可中包含；本许可并非旨在限制适用法律下任何权利的许可。 54 | 55 | 目录 56 | ================= 57 | 58 | **[目录](#table-of-contents)** 59 | 60 | **[表格和数字列表](#list-of-tables-and-figures)** 61 | 62 | **[动机](#motivations)** 63 | 64 | > [真正让加密货币进入下一阶段](#taking-cryptocurrency-to-the-next-level-literally) 65 | 66 | **[执行摘要](#executive-summary)** 67 | 68 | **[背景](#background)** 69 | 70 | > [区块链技术](#blockchain-technology) 71 | > 72 | > [加密货币](#cryptocurrency) 73 | > 74 | > [降价拍卖](#descending-price-auctions) 75 | 76 | **[Metronome 简介](#introducing-metronome)** 77 | 78 | **[Metronome 工作原理](#how-metronome-works)** 79 | 80 | > [跨区块链可迁移性](#cross-blockchain-portability) 81 | > 82 | > [分布式、自愿的共识 > 治理](#distributed-voluntary-consensus-governance) 83 | 84 | **[迄今为止的加密货币市场背景](#cryptocurrency-market-context-to-date) ** 85 | 86 | > [整体布局](#the-landscape) 87 | 88 | **[Metronome 合约和技术层面](#metronome-contracts-and-technical-aspects)** 89 | 90 | **[Metronome 收益和自治转换合约](#metronome-proceeds-and-autonomous-converter-contracts)** 91 | 92 | **[代币供应经济学](#token-supply-economics)** 93 | 94 | > [理论](#theory) 95 | > 96 | > [供应时间表](#supply-schedule) 97 | > 98 | > [Metronome 核心](#metronome-core) 99 | > 100 | > [代币 API](#token-api) 101 | > 102 | > [拍卖 API](#auction-api) 103 | > 104 | > [Metronome 收益合约](#metronome-proceeds-contract) 105 | > 106 | > [收益合约 API](#proceeds-contract-api) 107 | > 108 | > [Metronome 自治转换合约](#metronome-autonomous-converter-contract) 109 | > 110 | > [自治转换合约 API](#autonomous-converter-contract-api) 111 | > 112 | > [TokenLocker](#tokenlocker) 113 | > 114 | > [TokenLocker API](#tokenlocker-api) 115 | > 116 | > [TokenPorter](#tokenporter) 117 | > 118 | > [TokenPorter API](#tokenporter-api) 119 | 120 | **[合约条款术语表](#glossary-of-contract-terms) ** 121 | 122 | **[附录 A](#appendix-a) ** 123 | 124 | 表格和数字列表 125 | ========================== 126 | 127 | 图 1：USD 和 BTC 货币基数的比较 11 128 | 129 | 图 2：Metronome 合约之间的流动和相互作用 12 130 | 131 | 图 3：跨区块链可迁移性演示 15 132 | 133 | 图 4：流行的加密货币铸造 18 134 | 135 | 图 5：比特币和 Metronome 的铸造和供应比较 19 136 | 137 | 图 6：ZEC 和 MET 创始人保留权益之间的比较 20 138 | 139 | 表 1：当今加密货币之间的重要属性 140 | 比较 21 141 | 142 | 图 7：自治转换合约的工作原理 22 143 | 144 | 表 2：供应时间表 27 145 | 146 | 动机 147 | =========== 148 | 149 | 在 Metronome 的发展过程中，Metronome 创始人渴望从以前的加密货币中汲取教训，建立一个长期货币体系并将此作为唯一目的。考虑到这一点，Metronome 创始人看到了一个新的机会： 150 | 151 | - 从经济层面设计出可持久的东西 152 | 153 | - 引导去中心化金融产品 154 | 155 | - 确保平等取得代币分配 156 | 157 | - 确保自治、自治合约 158 | 159 | - 真正让加密货币进入下一阶段 160 | 161 | **从经济层面设计可持久加密货币** 162 | 163 | 一些加密货币的铸造或是静态的，或是随着时间的推移逐渐消失，比如比特币[^1][^2]和莱特币[^3]，这让经济学家质疑它们的长期生存能力。[^4][^5]其他加密货币的代币供应在前 ICO 交易中是手工完成的，这些交易给某些人提供了大量的代币供应，导致那些人控制了大多数代币。一些加密货币在预售阶段或私下就已出售给某些人，留给大众的很少。Metronome 试图 164 | 通过每日拍卖来解决这些问题。这些拍卖提供了持续代币供应，并且是永久供应。理论上，相对于铸币量要么为零要么趋于零的其他加密货币，持续代币供应提供了可持续性。[^6][^7]Metronome 团队期望这种方式也会鼓励 MET 持有人使用 Metronome 的许多支付功能。那些使用案例实际上是将其用作货币，可能有助于 165 | 巩固其耐久性。Metronome 团队还认为，持续铸币也会稀释在给定时间购买的任何潜在的不成比例的金额。Metronome 团队认为自己是在构建一项可持久工程。持久性是 Metronome 的主要目标。 166 | 167 | **引导去中心化金融产品** 168 | 169 | 将去中心化系统导向自我可持续性是一项新的事务，其中的艺术多于科学。Metronome 试图在这里开辟新天地。Metronome 拍卖的所有收益都将纳入两个独立的智能合约，[^8]这些智能合约旨在向可能要出售的 MET 所有者提供流动性。[^9] 170 | 171 | 鉴于所有拍卖收益都保留在 Metronome 生态系统内，Metronome 团队预计它会蓬勃发展。此外，该团队希望其他人研究 Metronome 的项目和产品模型。 172 | 173 | **确保平等取得代币分配** 174 | 175 | 加密货币应该更加平等。应该有不止 1% 的人可以使用世界上的下一代加密货币。与整个 Metronome 经济相比，向公众广泛发行加密货币可以减少涉众的数量。 176 | 177 | 降价拍卖旨在以买方认为公平的价格发行代币。[^10]其他 ICO 的代币发行是手工完成的，大多数代币通常在公众得知以前的预售阶段或私下里就已经出售了。[^11] 178 | 179 | Metronome 公司在其初始供应拍卖和每日总量批次上都采用了降价拍卖方式，公众可以获得所有拍卖机会。[^12]没有预售、白名单或任何奖金。参与 Metronome 拍卖的每个人都必须按照相同的规则进行操作：以给定价格购买或等待价格下降。在这些公开拍卖中没有人被排除在外或享有特权。[^13] 180 | 181 | Metronome 团队认为，初始供应拍卖这种方式可以阻止空间内的大型参与者和其他大型玩家支配 MET 的供应——因为获得不成比例的 MET 数量可能需要支付高于已知的市场价格。该团队还认为，这将鼓励在买方群体中实现更公平的分配。Metronome 并不是为短期投机者寻找一个快速脱手的机会，而是使初始供应拍卖的每个方面都试图提供更公平的 MET 获得和更公平的 182 | MET 分配。 183 | 184 | **自治、自治合约** 185 | 186 | 人类是容易犯错的。软件和数学在未来数十年及更长的时间内更具可预测性。算法不涉及政治，它不会在人类的自由支配下过度膨胀或操纵货币。有了自治、自治合约，[^14]没有人能根据人的判断力来影响加密货币的价值。为此，Metronome 智能合约的所有权职能将被锁定，以便在发行后无人可以取得它们的所有权。Metronome 采用完全自治方式。 187 | 188 | Metronome 被设计为具有自我调节和自治的能力。为此，Metronome 的合约是完全自治的，我们相信在没有创始人干预的情况下，其表现是可预测的。 189 | 190 | 真正让加密货币进入下一阶段 191 | ---------------------------------------------------- 192 | 193 | 其他每种加密货币都只与一个区块链网络相关联。LTC 只记录在莱特币区块链上。BTC 只记录在比特币区块链上。只与一个区块链相关联存在风险：管理不和谐、供应不确定性等。市场不知道跨区块链是可行的，更不用说有需求了。 194 | 195 | Metronome 是第一个永远不会只与一个区块链绑定的加密货币。这是第一个可能通过最好的区块链网络获得安全保障的加密货币，并且没有对任何一个区块链的永久承诺。这是一个全新的概念，即使在创新性的加密货币空间中也是如此。 196 | 197 | 执行摘要 198 | ================= 199 | 200 | Metronome（“Metronome”或“MET”）是一种新的加密货币，专为拥有机构级的耐久性而设计。Metronome 汲取了其他加密货币（如比特币和以太坊）的经验，其设计可适应未来 100 年甚至更长时间。 201 | 202 | Metronome 将以平等的机会向公众发行。Metronome 在发行后创始人将拥有零特权，并且具有高度可预测和可靠的代币供应。 203 | 204 | Metronome 代币供应： 205 | 206 | - 1 千万个初始 MET 代币供应 207 | 208 | - 8 百万个通过公开降价拍卖发行，详情如下 209 | 210 | - 2 百万个被分配给创始人由创始人持有（20%） 211 | 212 | - 根据特殊 TokenLocker 合约铸币（见 API 部分） 213 | 214 | - 在初始供应拍卖结束时，25% 可供创始人使用 215 | 216 | - 剩余的 75% 以等量分 12 个月获得 217 | 218 | - 只有 Metronome 的创始人才能撤销他们的 TokenLocker 合约，并且只能在上述特定时间撤销 219 | 220 | - 每日铸造新的 MET 221 | 222 | - 每日铸造的 MET 通过公开降价拍卖发行 223 | 224 | - 每日铸币量：(i) 每天 2880 个 MET 代币，或 (ii) 相当于每年当时未清偿 MET 代币供应 2.0000% 的年产率 225 | 226 | Metronome 的三个核心设计原则是自治、可靠性和可迁移性。它们使 Metronome 独特而持久。 227 | 228 | - **自治** 229 | 230 | - 在发行后，没有任何不当的创始人影响——由智能合约自治管理 231 | 232 | - 抵抗个人或社区不相容、分歧或曲解 233 | 234 | - 公众可获得所有销售机会 235 | 236 | - 100% 链上、去中心化、可审计 237 | 238 | - 通过降价拍卖定价 239 | 240 | - **可靠** 241 | 242 | - 可预测的代币供应 243 | 244 | - 每天永远以下列两者的较大者铸造新的 MET：(i) 每天 2880 个 MET 代币，或 (ii) 相当于每年当时未清偿 MET 代币供应 2.0000% 的年产率 245 | 246 | - 稳定、可预测的新代币永远供应铸造 247 | 248 | - 设计为可预测的价格 249 | 250 | - **可迁移性** 251 | 252 | - 跨区块链可迁移性能实现从不同合约或不同区块链的可证明导出和导入 253 | - 深层保护加密货币免受治理问题和不稳定因素的影响 254 | 255 | - 新区块链导出和导入功能的社区开发 256 | 257 | - 随着分类账技术平台的成熟，实现向未来区块链的迁移路径 258 | 259 | - **其他特性** 260 | 261 | - 初始付款预计将在 15 到 30 秒内结算——结算时间基于底层区块链 262 | 263 | - 批量支付——允许同批发送多笔付款 264 | 265 | - 预订——允许用户之间的定期付款 266 | 267 | - ERC20 符合其他定制功能 268 | 269 | 在本文件中，我们认为 Metronome 作为一种新的加密货币，它独一无二地满足了上述标准，是世界上第一个自治的、跨区块链加密货币。我们预计，加密货币和其他代币社区将针对这种情况重新设计自己的代币使用方式。 270 | 271 | 为了实现这一目的和实现自我治理，Metronome 的创始人在初始拍卖之后对 Metronome 代币没有任何特权。Metronome 公司将采用降价拍卖的方式进行初始拍卖和每日总量批次，以使买方有机会以他们认为公平的价格购买。 272 | 273 | 背景 274 | ========== 275 | 276 | 区块链技术 277 | --------------------- 278 | 279 | 区块链是一种新型的加密安全记录技术，在金融领域有着重要的影响。它是一种分布式的、通常是去中心化的分类账，适用于其整个生态系统中的所有单元。在整个网络中，公共和完整的分类帐需要同步并相互一致。这些被称为节点。节点可以防止区块链单元的“双重支出”，也可以验证网络块中的交易。 280 | 281 | 块是打包的交易数据、前一个块的散列、目标散列以及一个称为随机数的数字。在节点验证这些块的地方，矿工尝试发现一个使得块中所有数据的散列符合其目标散列的随机数，从而将它们写入区块链。矿工付出了努力和计算能力，会因此得到新铸造的加密货币单位作为奖励。 282 | 283 | 区块链的“链”指的是矿工为去中心化公共分类账所写的不间断的矿块线。矿工必须将之前区块的数据整合起来，才能成功地发现新的区块，从而将可追溯的历史记录到加密货币的最开始。 284 | 285 | 加密货币 286 | -------------- 287 | 288 | 加密货币是一种数字货币，它使用加密技术来调节市场中新增的货币供应。通常，成功发现上述挖掘过程中的块后，以新发行加密货币作为奖励。密码学还验证了资金转手的有效性。只有交易用户持有的私钥才能为用户钱包之间的资金转移提供授权。由于这些交易在区块链上是可见的（见上文），并且使用加密密钥确保用户打算发送资金并有足够的资金进行交易，因此，凭借第三方来转移和验证账户之间资金转移的需求减少了。加密技术取代了 289 | 清算所和其他中介机构的角色。因此，加密货币有可能为货币供应和法定货币发行提供更大的可预测性。 290 | 291 | 法定货币的发行和供应可以由发行机构进行多方面管理，而加密货币的行为必定符合其设计意图。因此，相对于预测法定货币的货币供应和铸币率，人们更容易预测加密货币的货币供应量和货币率。 292 | 293 | ![图 1：美元货币基础与比特币的代币基础之间的比较](img/figure-1.jpg) 294 | 295 | *图 1：美元货币基础与流行的 296 | 加密货币（比特币）代币基础之间的比较*[^15] 297 | 298 | 自比特币之后，人们创造了其他各种加密货币。这些加密货币共同组成了一个活跃而充满活力的市场。 299 | 300 | 降价拍卖 301 | ------------------------- 302 | 303 | 目前，大多数新的加密货币都以传统销售方式提供初始支付。这些销售可能包括奖金、早期买方的定价，以及其他鼓励买方购买所有产品的激励措施。尽管这些激励措施行之有效，但它们并不能保证售出，并且可能导致公共访问不对称。此种模式不适用于以持久性为主要目标的加密货币。Metronome 团队选择使用不同方法来避免这种模式。 304 | 305 | Metronome 团队决定采用降价拍卖作为其初始供应拍卖和每日总量批次的模式，这可能提供有趣的机会和更公平的 MET 分配。降价拍卖始于高起始价格。随着拍卖的进行，价格会降低，直到所有单元均售出，或达到预定的底价，或达到拍卖时限而拍卖结束。我们认为市场价格的发现是快速和公平的，因为每个买方在购买时支付自己认为公平的价格。[^16]如果买方认为拍卖价格太高或不公平，可以等价格下降到他们认可的水平再购买，当然，前提是仍有剩余供应。 306 | 307 | Metronome 团队选择了这一机制，致力于减轻大型参与者控制 MET 不成比例的供应，提供平等的拍卖机会，并实现更公平的 MET 分配。 308 | 309 | Metronome 简介 310 | ===================== 311 | 312 | Metronome 是一款新型加密货币，最大特点是自治、持久、长期可靠性和最大可迁移性。Metronome 专为拥有机构级的耐久性而设计，它汲取了之前发布的其他加密货币的经验教训，其设计可适应未来的 100 年或更久远。我们相信 Metronome 是一款能够存续上千年的加密货币。 313 | 314 | Metronome 的工作原理 315 | =================== 316 | 317 | ![图 2](img/figure-2.jpg) 318 | 319 | *图 2：以太坊区块链上的 Metronome 合约之间的流动和相互作用* 320 | 321 | **发行** 322 | 323 | Metronome 团队的目标之一是提供更公平、更平等的拍卖机会以及 MET 供应。Metronome 的初始供应拍卖和每日总量批次使用降价拍卖 (DPA) 模式。与传统拍卖不同，在降价拍卖中，每个代币的价格从最高价开始拍卖，然后价格慢慢下降，直至所有供应售罄或拍卖结束。Metronome 使用 DPA 旨在建立 324 | 透明可预测的定价。[^17] 325 | 326 | 初始供应拍卖的起拍价为每个 MET 代币等于 2 个 ETH。只要拍卖开放并且仍有 MET 可供购买，价格将每 60 秒钟下降 0.0001984320568 ETH，价格下限为 0.0000033 ETH。 327 | 328 | 买方实时购买 Metronome 加密货币，并在购买后几乎立即取得其 Metronome。初始供应拍卖期间购买的 Metronome 在初始供应拍卖结束之前不可转让，而在每日总量批次期间购买的 Metronome 在取得后可立即转让。 329 | 330 | Metronome 团队认为，以这种方式拍卖使买方有机会以他们认为合理的价格买到 MET，当然，前提是降到该价格时仍有可供购买的 MET。相对于纯荷兰式“每个人都可获得最终价格”拍卖，降价拍卖还会提供更为准确的市场价格发现。原因很简单，因为如果买方愿意高于该价格来支付，说明最终价格本质上被低估了。 331 | 332 | 这种方法还可以减少大型参与者在拍卖中吸收大量 MET 的机会，因为购买大量不成比例的 MET 的成本可能高于新产生的市场价格。纯荷兰式拍卖仍会以不成比例的价格将 MET 分销给早期买方。 333 | 334 | 尽管许多供应购买方案是可接受的，但值得强调的是：涓涓细流随后却是汹涌急流。在这种情况下，买方以较高的价格购买少量供应。一旦定价低于某个阈值，剩余的供应可能会被迅速消耗。 335 | 336 | **阶段 1：初始供应拍卖** 337 | 338 | - 初始代币供应为 1 千万个代币。 339 | 340 | - 20% 的初始代币供应由创始人持有。 341 | 342 | - 根据特殊 TokenLocker 合约铸币（见 API 部分） 343 | 344 | - 在初始供应拍卖结束时，25% 可供创始人使用。 345 | 346 | - 剩余的 75% 以等量分 12 个月获得 347 | 348 | - 只有 Metronome 创始人才能撤销他们的 TokenLocker 合约，并且只能在上述特定时间撤销 349 | 350 | - 降价拍卖 8 百万个代币（即 1 千万个 MET 的初始代币供应总数减去创始人持有的 20% 代币供应）。 351 | 352 | - 初始供应拍卖至多持续 7 天。 353 | 354 | - 初始供应拍卖价格定为每个 MET 等于 2 个 ETH，价格下限为 0.0000033 ETH。 355 | 356 | - 在初始供应拍卖中，MET 拍卖价格每 60 秒钟就直线下降 0.0001984320568 ETH。 357 | 358 | - 拍卖持续进行，直至 8 百万个代币存货售罄或拍卖在 7 整天（10080 分钟）后结束。 359 | 360 | - 初始拍卖所得收益的 100% 纳入收益合约中。 361 | 362 | **阶段 2：操作货币** 363 | 364 | - 在原拍卖结束后，新代币每 24 小时永远按以下两个速率中较大者添加到每日总量批次中：(i) 每天 2880 个 MET 代币，或 (ii) 相当于每年当时未清偿代币供应 2.0000% 的年产率。 365 | 366 | - 每 24 小时发起一次拍卖，每次拍卖持续时间不超过 24 小时（为避免拍卖重叠）。 367 | 368 | - 在每日总量批次中，所有代币的降价拍卖从最高价开始，最高价为前一次拍卖收盘价（*例如*，如果拍卖售罄，即为售出的最后一个代币的价格，或者拍卖暂停时的价格）的两倍。 369 | 370 | - 如果在给定的每日总量批次中 Metronome 的售出量为零 (0)，则次日的每日总量批次价格将从每日总量批次中售出的最后一个 Metronome *价格的 1/100 开始拍卖*。 371 | 372 | - 每 60 秒钟，拍卖价格就降到原来价格的 99%。 373 | 374 | - 拍卖持续进行，直至 (i) 每日总量批次存货全部售罄，或 (ii) 24 小时的拍卖结束，以上述两者中较早者为准。 375 | - 如果每日总量批次存货没有售罄，剩余 MET 将计入次日的每日总量批次中。 376 | 377 | - 每日总量批次的明确价格下限为 1 Wei。 378 | 379 | - 每日总量批次所得收益的 100% 转移给收益合约。 380 | 381 | - 每隔 24 小时，收益合约总累计余额的 0.25% 就转移给自治转换合约（如下所述），以便 MET 所有者可以出售其 MET。 382 | 383 | 跨区块链可迁移性 384 | ---------------------------- 385 | 386 | ![图 3](img/figure-3.jpg) 387 | 388 | *图 3：跨区块链可迁移性演示* 389 | 390 | Metronome 独有的特点之一就是跨区块链可迁移性，它允许用户出于任何原因将 MET 从一个区块链移动到另一个区块链。如果用户决定移动自己的 MET，用户必须首先向将接收 MET 的目标区块链做出承诺。用户再从源区块链 A 上的代币供应中删除其 MET 并收到“退出证明”二叉树[^18]收据。然后，用户将此收据提供给目标区块链 B 上的 Metronome 合约。 391 | 392 | 在这种情况下，区块链 A 上的 MET 代币供应减少，区块链 B 上的代币供应通过此导出/导入过程增加。自治的每日总量批次在区块链 A 和区块链 B 上按比例调整，以反映区块链 A 和 B 中 MET 的新分配。例如，如果区块链 A 和区块链 B 上各存在所有 MET 中的 50%，那么 A 链和 B 链上的每日拍卖都应该是每天 1440 个代币。 393 | 394 | 导出/导入系统 395 | ---------------------------- 396 | 397 | Metronome 基于其他区块链而构建，这样有助于巩固其自治性质和提高持续存在能力。由于缺乏链条持久性，保持像全球供应这样的常量比使用单区块链加密货币来保持该常量更棘手。因此，Metronome 的导入和导出功能最初分三个阶段推出。随着区块链技术的持续发展进步，其他阶段可能会进一步分散和改善 Metronome 生态系统。 398 | 399 | 在高层次上，Metronome 可迁移性的组成部分有： 400 | 401 | **导出** 所有者可以通过调用导出函数将 MET 从一个区块链上移动到另一个区块链上。这一函数接受用户的 MET，在本地区块链上将它销毁，并以二叉树收据的形式向用户提供一个 ExportReceipt。所有者将以 MET 形式支付一笔小额费用，这笔费用由验证者索取。此收据可用于在目标区块链上认领 MET - 从而有效地将所有者的 MET 从源区块链上移动到目标区块链上。 402 | 403 | **导入** 任何用户都可以将 ExportReceipt 提供给预定的目标 Metronome 合约。他们调用 importMET 并提供 ExportReceipt。处理完毕后，目标区块链将 MET 转移给原始接受者。完成 Metronome 导入的用户将在 MET 中获得上述费用用于其认证。 404 | 405 | 然而，由于 Metronome 支持多区块链，真实来源可能存在于这些区块链中的任何一个上。因此，需要在导入和导出中进行验证。 406 | 407 | **验证** 在导入和导出过程中，验证者需要： 408 | 409 | 证明在硬分叉的情况下哪些区块链是有效的 410 | 411 | 提供额外信息（如事件证明）以验证特定的导入。 412 | 413 | Metonome 的导入/导出基础设施将分三个阶段推出。Metronome 将与第一版一起发行，未来的升级将加入现存的 Metronome 合约。 414 | 415 | 从概念上讲，验证者在 Metronome 生态系统中的作用类似于其他加密货币中的“矿工”。他们验证并证实 Metronome 的分散真实来源。导出者将在 MET 中向验证者支付可选费用。 416 | 417 | 验证阶段的系统设计（如下所述）旨在保证： 418 | 419 | Metronome 的全球供应量从不超过每日 10,000,000 + 2880（或每年当时未清偿供应的 2%，以较大者为准）。 420 | 421 | 验证者不能审查个人交易。 422 | 423 | 避免验证者间产生分歧（见下文）。 424 | 425 | 其他区块链上的 Metronome 合约可以探测出分歧并“标记”不安全的区块链，最终将其隔离直至它们解决所标识的问题。 426 | 427 | 验证阶段 428 | ---------------------------- 429 | 430 | 阶段 1：验证者通过 ExportReceipt 的散列检查并验证每张导出收据。当足够数量的验证者认定给定的散列有效时，任何人都可以通过验证收据完成 Metronome 的导入。 431 | 432 | 阶段 2：验证者保存所有导出收据的历史清单，创建收据散列的二叉树，并验证那些树的二叉树根。然后导入者向验证者和用户提供导入证明。导入证明包括二叉树收据和成对的证明事件根源的散列。 433 | 434 | 阶段 3：验证者验证 Metronome 所在的每个区块链的散列。导入者提供以下证明： 435 | 436 | - 通过二叉树路径证明导出事件位于导出链上的某个区块头中。 437 | 438 | - 证明区块事件与经过验证的链散列相对应。 439 | 440 | 不合格参与者的保证和安全措施 441 | ---------------------------- 442 | 443 | 由于具有可信赖参与者的阶段 1 验证模型证明了自身，所以社区和团队将继续迭代验证机制，从而使其更加分散。目前，最理想的去中心化水平可能在阶段 3 之后才能达到。验证模型中更大的权力去中心化会以多种方式增加安全性，但仍存在参与者因“非理性”原因而行为不当的可能性。为了解决这个问题，当面对链对链攻击、Metronome 其他分支的故障以及各种其他欺诈类型或错误类型的问题时，系统架构必须具有迅速恢复的能力。 444 | 该系统仍在制定中，但广义而言，我们将使用来自更好的权益证明系统的核心概念，结合一些工作量证明概念。Metronome 计划对不合格的参与者“软硬兼施”。Metronome 的基本规则是（并将永远是）：供应量是固定的，用户知道 Metronome 体系的哪些部分是安全的，并且能够将其 MET 导出到安全的地方。 445 | 446 | 分布式、自愿的共识治理 447 | ------------------------------------------- 448 | 449 | 这种治理模式基于 MET 持有者社区的自愿共识，能够将 Metronome 从其创始人发起的最初“开端”链导出，并导入到其创始人或其他方面发布的后续升级。该功能为两个不可变的合约同时提供了机会，也提供了公平的分配机制来随着市场的成熟而升级这些合约。 450 | 451 | 例如，如果市场需求量大大超过供应，并且起初 MET 的真实价格上涨超出商家的实际价格，则有些人可能会同意在相同或不同的区块链中，通过将他们控制的资金导出新的分支以新的 MET 合约分散 MET 供应。这些动态有可能消除代币供应曲线中先验设计所带来的风险，因为新的不可变的 MET 合约可以升级代币供应曲线以获得更大的商业用途。 452 | 453 | 同样，如果市场供应量开始超过需求量并持续一段时间，而且价格下跌，那么不同 MET 分支的持有人可能会同意从多个导出源“合并”到单一输入目的地。这种自愿的共识机制可减少 MET 的总经济活跃供应，从而在需求量减少、价格保持稳定的情况下，使代币供应减少。 454 | 455 | 至于分支和新链条的移动如何影响 MET 代币供应曲线和发行，在 Metronome 社区中尚无定论。我们诚邀您参与定义、实施、分散和合并您自己的新 MET 目标合约，将 MET 导入新合约，并查看会发生什么情况。 456 | 457 | 迄今为止的加密货币市场概述 458 | ===================================== 459 | 460 | 为更好地理解 Metronome 对加密货币世界的适应性，我们需要从更高的角度在整体布局上进行讨论。 461 | 462 | 整体布局 463 | ------------- 464 | 465 | 我们来看几种有名的加密货币，考察其代币供应定位、发行计划以及该计划抗经济恢复力和经济不稳定性的能力。 466 | 467 | ![图 4](img/figure-4.jpg) 468 | 469 | *图 4：目前流行的加密货币铸造，注：ETH 是一种预测*[^19] 470 | 471 | 比特币（“Bitcoin”或“BTC”）出现于 2009 年 1 月 5 日，大众可以公平地参与该货币生态系统以及进行货币挖掘。[^20]每一个区块出现都会有新的货币供应。每 2016 个区块内，各区块生成时间间隔目标值为 10 分钟。货币供应量为每个区块 50 个比特币，每四年减少一半。 472 | 473 | 比特币社区精神高度重视比特币 2100 万货币供应限制的不变性，以及发行计划的不变性。一旦达到这一限制，新的比特币挖掘就会停止，交易费用就成为推动矿工进行比特币挖掘的因素。比特币社区内部普遍存在争议，即当货币发行量下降到极低的水平时，交易费用是否足以让比特币获得资金和安全保障。[^21] [^22] 如果比特币今天重新开始，它当前的绝对通缩性质是否会被持久的温和通胀特征所取代，从而刺激矿工为该网络提供无限期的安全保障呢？很有可能。人们期望低水平的通货膨胀，因为它不鼓励囤积资源、*鼓励*投资，就加密货币而言，还会在货币挖掘过程中持续为区块链提供安全保障。[^23] 474 | 475 | ![图 5](img/figure-5.jpg) 476 | 477 | *图 5：比特币和 Metronome 的铸造和流通供应比较*[^24] 478 | 479 | 今天的用户依赖发行计划的可预测性和不变性。可预测性让市场用户有能力对未来数年甚至数十年进行规划。不变性确保了货币供应不受人类的突发奇想和精神脆弱的影响。然而，比特币社区中有各种各样的团体对影响网络治理感兴趣，使社区出现了争议性分支、不确定性和见解。 480 | 481 | 莱特币（“Litecoin”或“LTC”）是仿照比特币形成的。[^25] 区块生成时间间隔为 2.5 分钟。货币供应量为每个区块 50 个莱特币，每四年减少一半。从货币发行的角度来看，莱特币基本上是比特币的复制品：发行计划在社区内大多数人来看是不变的。和比特币一样，其新货币发行量会随时间递减。莱特币的管理和比特币类似，但前者对货币生态系统中的明星人物会给予一些习惯性尊重。 482 | 483 | 大零币（“Zcash”或“ZEC”）也和上述货币类似。工作量证明挖掘对所有人开放。区块生成时间间隔为 2.5 分钟。货币供应量为每个区块 12.5 个大零币，每四年减少一半。特别的是，前 2 万个区块的大零币释放速率相对缓慢，之后才逐渐提高到 12.5 个大零币的释放速率。大零币的开发团队和支持协议开发团队不会一次性将挖掘的货币补偿给矿工，而是会对所有新生成的区块收取代币挖掘量的 10% 作为创始人报酬，直至发行四年后代币供应第一次减半才停止收取。这之后，挖掘出的代币将全部归矿工所有。[^26]大零币基金会旨在成为其货币生态系统自愿治理的天然中心。[^27] 484 | 485 | ![图 6](img/figure-6.jpg) 486 | 487 | *图 6：ZEC 和 MET 创始人保留权益与 488 | 流通供应之间的比较*[^28] 489 | 490 | 以太坊（“Ethereum”或“ETH”）预售筹集了超过 6 千万个以太币，这些都是在开端区块上预挖掘获得的。[^29] [^30] 每生成一个新的区块会供应 5 个以太币。新的货币供应 T+1Y 增长了 19.8%，T+2Y 增长了 21.2%，T+3Y 增长了 17.4%。此后货币增长量逐渐下跌。广为流行的观点是，以太坊货币发行计划不断变化，会随着系统的发展进行改变。[^31]以太坊计划变更其权益证明，这可能会使其发行也有所改变。[^32]因此以太币的发行是可变的，目的是保证其恢复力和可持续性。尽管任何改变都需要货币社区和矿工的支持，但整个社区通常对小部分创始团队非常尊重和信赖。 491 | 492 | 瑞波币（“Ripple”或“XRP”）的对外供应总数为 380 亿个瑞波币。[^33]其管理公司 Ripple Inc. 还额外拥有 610 亿个瑞波币，其中 550 亿个瑞波币由第三方托管。[^34]瑞波币实行集中管理，Ripple, Inc. 控制着该加密货币生态系统的很大部分。Ripple Inc. 直接管理市场上瑞波币的发行，因此瑞波币发行计划高度可变。Ripple Inc. 保留了不成比例的管理权力。 493 | 494 | Metronome 从这些数字货币中吸取了教训，形成一种专为拥有机构级耐久性而设计的加密货币，以发行、治理和可靠性作为其体系结构的主要原则。这种货币具备完全自治性，创始人无法对其施加不正当影响从而违背自我治理的设计目标。Metronome 具备可预测性，以可预测的速率铸造新的 MET，使其保持稳定。用户还可以任何其认为适当的理由在区块链之间转移货币，使其具有可迁移性。 495 | 496 | | | BTC[^35] | LTC[^36] | ETH[^37] | XRP[^38] | ZEC[^39] | MET | 497 | |--|--|--|--|--|--|--| 498 | | **可靠性** | BTC 以其争议性分支和通缩特性而闻名。货币供应和发行稳定，但是有一定限度。| 与 BTC 一样，LTC 的发行和供应受到严格限制，这可能威胁到区块链稳定性。| ETH 的发行和供应模式不断变化。它在过去已经出现过分支。| XRP 的供应稳定，完全由 Ripple Inc. 管理。| 与 BTC 类似，ZEC 受到严格限制，这可能使未来区块链的安全性受到质疑。| **MET 的发行和供应将严格遵循合约，始终可预测。其供应或发行不存在不确定性。** | 499 | | **自治** | BTC 具备自我治理性，但有许多团体想要施加不正当的影响。| LTC 具备自我治理性，但社区对明星人物持有习惯性尊重。| 对 ETH 的改变需要社区的支持，但更依赖于一个小团队。| XRP 不具备自我治理性。Ripple Inc. 保留管理 XRP 的唯一权力。| Zcash 基金会是自愿治理的天然中心。| **MET 通过自治合约实现完全的自我治理。** | 500 | | **可迁移性** | 否 | 否 | 否 | 否 | 否 | **是** | 501 | | **不变性** | 强 | 强 |可变；会随着 PoS 而改变 | 弱 | 强 | **强** | 502 | | **发行模式** | 每 10 分钟 50 个 BTC。每四年减少一半。| 每 2.5 分钟 50 个 LTC。每四年减少一半。| 每 15 秒 5 个 ETH。| Ripple Inc. 发行过一次。| 每 2.5 分钟 12.5 个。每四年减少一半。| **MET 日拍卖量为（以如下两者中较高者为准）：(i) 每天 2880 个 MET，或 (ii) 相当于每年当时未清偿代币供应 2.0000% 的年产率** | 503 | | **供应限制** | 2100 万 | 8400 万 | 未知 | 1000 亿 | 2100 万 | **参见上述发行模式** | 504 | | **结算时间** | 10 分钟 | 2.5 分钟 | 15 秒 | 5 秒 | 2.5 分钟 | 15 秒 | 505 | | **批量支付特征** | 是 | 是 | 否 | 否 | 是 | **是** | 506 | | **认购特征** | 否 | 否 | 否 | 否 | 否 | **是** | 507 | 508 | *表 1：当今加密货币之间的重要属性 509 | 比较* 510 | 511 | Metronome 合约和技术层面 512 | ========================================= 513 | 514 | 四个自治智能合约构成了 Metronome。一般流程为： 515 | 516 | 1. 第一份合约是 MET 代币和分类账，与区块链直接进行交互。它支持用户进行点对点交易结算，并用作分布式财富存储。它采用大家熟知的具备定制功能的 ERC20 代币标准，具有更高的安全性和转移性。 517 | 518 | 2. 代币合约之后是拍卖合约。用户通过拍卖合约购买 MET。当用户通过拍卖合约购买时，合约为该用户铸造 MET。 519 | 520 | 3. 之后拍卖合约会把收益发送给第三份合约——收益合约。初始供应拍卖的每个每日总量批次所得收益的 100% 都将从拍卖合约转移给收益合约。 521 | 522 | 4. 每隔 24 小时，收益合约将其 0.25% 的收益发送给第四份合约——自治转换合约，为其提供可用的 ETH。当用户向自治转换合约发送 ETH 或 MET 时，合约按各自规定的费率退回 MET 或 ETH。由于自治转换合约中的代币比例决定了它们的相对价值，我们预计套利行为会使定价大致准确。如果合约拥有的 MET（或 ETH）太少，那么与对应合约相比，其价格会相对高昂。如果用户认为自己的 MET（或 ETH）不值那么多，那么该用户会用自己的代币换取其他代币。这样可以平衡合约收益，消除相对价格不平衡。 523 | 524 | Metronome 收益和自治转换合约 525 | ===================================================== 526 | 527 | 所有拍卖的一切收益都保留在 Metronome 生态系统中，意图为 Metronome 及其用户构建持久的生态系统。通过确保拍卖中的所有收益保持在合约链中——并且不受任何群体的控制，我们相信 Metronome 可以保持更长和更自治的持久性。 528 | 529 | 此流程以拍卖合约为起点，合约购买方在拍卖中购买 MET 时与此合约进行交互。然后，收益合约取得拍卖合约的收益，并将一部分导出给自治转换合约，为自治转换合约提供 ETH 供应以进行购买和销售。MET 将在自治转换合约中进行初始化。 530 | 531 | 在初始供应拍卖和每个后续的每日总量批次中，所得收益的 100% 将转移给收益合约。没有收益分配给 Metronome 创始人。收益合约每天将其累计收益总额的 0.25% 转至自治转换合约。相比直接在自治转换合约中结算收入，我们预计这可能使每日拍卖量的差异较为平滑。 532 | 533 | 当向自治转换合约出售 ETH 时，合约中特定数量的 ETH 可获得的 MET 数量会增加。这时如果有人出售 MET 并购买 ETH，他们将获得更多的 ETH，如果有人想使用自治转换合约购买 MET，必须支付更多的 ETH。 534 | 535 | 如果自治转换合约中的 ETH 日销售量将 MET 的价值提高到高于市场可支持的水平，我们相信套利行为将捕获超额 ETH。但是，考虑到 Metronome 的可预测性是以数十年的时间尺度来衡量的，我们预计市场将在自治转换合约可用的 ETH 流量中进行预测和定价。 536 | 537 | ![图 7](img/figure-7.jpg) 538 | 539 | *图 7：与自治转换合约及其后端进程进行交互的用户体验* 540 | 541 | **经济预测** 542 | 543 | 虽然自治转换合约试图接近市场确定的价格，但拍卖合约每天都有固定的定价计划。所以： 544 | 545 | - 当拍卖的代币价格高于自治转换合约的代币时，预计买方不太可能从拍卖中购买代币。买方从自治转换合约中购买更便宜的代币显然更划算。 546 | 547 | - 当拍卖的代币价格低于自治转换合约的代币时，任何人都可以通过在拍卖中购买代币并将其出售给自治转换合约以获得套利利润。通过套利可以消除自治转换合约中 ETH 存在的不平衡。但是，由于每个人都希望这样做，因此预计拍卖会在价格出现明显差异之前售罄。 548 | 549 | 总之，预计拍卖中的买方会试图以非常接近自治转换合约当前价的价格在拍卖中购买代币，每个交易日中较晚加入的买方能够从较早买方那里获利，本质上补偿了他们在拍卖中无法购得的风险。 550 | 551 | 每日总量批次一旦给出，向自治转换合约出售可以满足超额需求，同时可能会提高代币价格。我们预计每次拍卖都会售罄，因为价格最终会下降到低于市场价格。 552 | 553 | **数学例子** 554 | 555 | 当用户与自治转换合约进行交易时，总会存在价格滑点，因为用户正在改变代币供应之间的比例。公式可以确定所有价格，例如不管用户进行大量的小额购买还是一次性大额购买，结果都一样。[^40] 556 | 557 | 有两个公式：一个用于计算用户获取 MET 或 ETH 的智能代币数量，另一个用于确定用户获取智能代币的 MET 或 ETH 数量。智能代币永远不会向用户公开。 558 | 559 | 建立准确有效的“初等函数”是一项重大的工程任务。因为以太坊只有 256 位整数，所以新的实施是必要的。 560 | 561 | 通过将自治转换合约限制为两个加密货币——MET 和 ETH（储备率为 0.5），数学推导得以简化并且只需要一个平方根，这很容易实施并且可以合理有效运行。 562 | 563 | 数学例子如下： 564 | 565 | *R* = 储备代币余额 566 | 567 | *S* = 智能代币供应 568 | 569 | *F* = 恒定储备率 570 | 571 | *T* = 交换储备代币 E 取得的智能代币 572 | 573 | *E* = 交换智能代币 T 取得的储备代币 574 | 575 | 原来的公式是：[^41] 576 | 577 | *T* = *S*((1 + $\frac{E}{R}$)${{}^{}}^{F} - 1$) 578 | 579 | *E* = *R*(1 - (1 - $\frac{T}{S}$)${}^{\frac{1}{F}}$) 580 | 581 | 在我们的例子中，因为 F 被设置为 0.5，该公式使用了定点乘法、除法和平方根： 582 | 583 | *T* = *S*($$) - 1) 584 | 585 | *E* = *R*(1 - (1 - $\frac{T}{S}$)${}^{2}$) 586 | 587 | **一个成功的例子** 588 | 589 | 假设自治转换合约有 1000 个 ETH 和 2000 个 MET，并且有 10000 个智能代币。自治转换合约的 MET 价格为 0.50 ETH。某用户认为数量偏多，希望用 100 个 MET 交换 ETH。在当前名义价格下，他会获得 50 个 ETH，但由于价格下滑，用户实际不会得到这么多。 590 | 591 | **第一步**：用 100 个 MET 交换智能代币。 592 | 593 | T?=?S?(v1+ E/R )-1) 594 | 595 | T? = 10000( v1 + 100/2000 ) - 1) = 10000( v1.05 - 1) = 10000(1.0247 - 1) = 10000(0.0247) = 247 596 | 597 | 用户取得 247 个新铸造智能代币。智能代币的供应总数现在为 10247。自治转换合约中 MET 的供应总数现在为 2100。 598 | 599 | **第二步**：将 247 个智能代币转换为 ETH，由合约自动完成，用户永远不会接触到智能代币。 600 | 601 | 假设 1000 个 ETH 是公式中的储备供应： 602 | 603 | *E* = *R*(1 - (1 - $\frac{T}{S}$)${}^{2}$) 604 | 605 | *E* = 1000(1 - (1 - $\frac{247}{10247}$)${}^{2}$) = 1000(1 - (1 - 0.0241)${}^{2}$) = 1000(1 - .976${}^{2}$) = 1000(1 - 0.953) = 1000(0.047) = 47 606 | 607 | 用户以 100 个 MET 取得 47 个 ETH。 608 | 609 | 该合约现在包含 953 个 ETH 和 2100 个 MET，或者说每个 MET 对应 0.45 个 ETH。通过出售一些 MET，用户使自治转换合约中 MET 的价格相对于 ETH 降低了。用户大约以初始价格和最终价格的中间价格取得 ETH。 610 | 611 | 这 247 个智能代币在交易时会被销毁，从而将智能代币供应降低到 10000。 612 | 613 | **交易订单减少** 614 | 615 | 用户可以预测自己的交易结果，前提是在该用户交易之前没有其他交易。这一点无法保证；事实上，其他参与方可以看到用户的交易正在进行，并发布自己的交易订单。矿工可以非常有效地做到这一点。 616 | 617 | 为了减少交易订单，我们要求用户指定最低回报。如果用户的交易回报低于此值，交易将会撤销；该用户仅需支付一小笔交易费以支付执行交易的计算成本。 618 | 619 | 代币供应经济学 620 | ====================== 621 | 622 | 理论 623 | ------ 624 | 625 | - 供应的可预测性使市场参与者能够准确地测量未来 12 个月、5 年、50 年内的供应量 626 | 627 | - 定价通过降价拍卖决定 628 | 629 | **供应** 630 | 631 | - 初始供应：1 千万个代币，通过降价拍卖 632 | 633 | - 初始供应后的供应量：年供应量为以下两者中的较大者：(i) 每天 2880 个 MET 代币，或 (ii) 每年当时未清偿代币供应的 2.0000% 634 | 635 | - 拍卖几乎实时结算 636 | - 一些经济学家认为，由于每个人都以自己的底价支付，因此可以发现拍卖的最佳价格[^42] 637 | 638 | ### 供应时间表 639 | 640 | | 时间 | 流通 MET 代币 | 铸币率 | 每日铸币量 | 641 | |--|--|--|--| 642 | | T + 1 年 | 11,051,200 | 10.512% | 2,880 | 643 | | T + 2 年 | 12,102,400 | 9.512% | 2,880 | 644 | | T + 3 年 | 13,153,600 | 8.686% | 2,880 | 645 | | T + 5 年 | 15,258,880 | 7.399% | 2,880 | 646 | | T + 10 年 | 20,517,760 | 5.400% | 2,880 | 647 | | T + 50 年 | 63,499,700 | 2.000% | 3,411 | 648 | | T + 70 年 | 94,382,561 | 2.000% | 5,070 | 649 | 650 | *表 2：供应时间表* 651 | 652 | **API 参考** 653 | 654 | Metronome 核心 655 | -------------- 656 | 657 | ### 代币 API 658 | 659 | 用于查询和转移 MET 代币的代币 API 是常见的 ERC20 代币标准。[^43] Metronome 还利用定制功能使自身符合增强的去中心化资金转移和安全性的最新标准。这些改进还使转移更容易对接收合约调用任何函数，允许数据和价值的转移，这一点是 ERC20 代币标准不能单独完成的。Metronome 很自豪能够使用最先进的技术。 660 | 661 | **标准 ERC20** 662 | 663 | | const name | Metronome | 664 | |--|--| 665 | | const symbol | MET | 666 | | const decimals | 18 | 667 | | function totalSupply | 符合 ERC20；参考 ERC20 标准。 | 668 | | function balanceOf | 符合 ERC20；参考 ERC20 标准。 | 669 | | function transfer | 符合 ERC20；参考 ERC20 标准。 | 670 | | function transferFrom | 符合 ERC20；参考 ERC20 标准。 | 671 | | function approve | 符合 ERC20；参考 ERC20 标准。 | 672 | | function allowance | 符合 ERC20；参考 ERC20 标准。 | 673 | | event Transfer | 符合 ERC20；参考 ERC20 标准。 | 674 | | event Approval | 符合 ERC20；参考 ERC20 标准。 | 675 | 676 | **定制代币函数** 677 | 678 | 679 | 680 | 681 | 682 | 684 | 685 | 686 | 687 | 688 | 689 | 690 | 691 | 692 | 693 | 694 | 695 | 696 | 697 | 698 | 699 | 700 | 701 | 702 | 703 | 704 | 705 | 706 | 707 | 708 |
Function multiTransfer(uint[] bits) 允许在单个交易中进行多次资金转移。位数组中的每个 uint 表示一次资金转移； 683 | 最左边的 160 位是地址，右边的 96 位是数额。
function setTokenPorter(address _tokenPorter) public onlyOwner returns (bool)为 TokenPorter 设置合约，负责导出功能，这只能由所有者运行
function mint(address _to, uint _value) public returns (bool)只有铸币者和 tokenporter 才允许铸造
function destroy(address _from, uint _value) public returns (bool)只有铸币者和 tokenporter 才允许销毁
function enableMetTransfers() public returns (bool)此函数将实现 MET 转移，并且只有在初始拍卖结束后才能成功调用。
function export(bytes8 _destChain, address _destMetronomeAddr, address _destRecipAddr, uint _amount, bytes _extraData) public returns (bool)将 MET 导出到 Metronome 支持的另一个区块链。
709 | 710 | **二叉树** 711 | 712 | 下列函数不适合手动使用，但有人 713 | 认为它们可以作为有趣的 UI 功能的基础。 714 | 715 | | 函数 setRoot(bytes32 root) | 设置与 msg.sender 关联的二叉树根 | 716 | | ------------------------------------------------------------------- | -------------------------------------------------------- | 717 | | Function rootsMatch(address a, address b) constant returns (bool) | 如果两个地址具有匹配的根，则返回 true。 | 718 | | function getRoot(address addr) public view returns (bytes32) | 获取与该地址关联的二叉树根 | 719 | 720 | **预订** 721 | 722 | 这些函数是唯一 Metronome 功能的一部分：区块链上的预订。用户能够通过预订促进 723 | 其他用户和机构之间的关系和定期付款。用户通过授权他们提取每周付款来预订。 724 | 然后授权组或个人可以将付款从用户账户转移到他们认为合适的任何账户。用户可以在必要时 725 | 取消预订。 726 | 727 | 这解决了其他加密货币一直面临的问题。对许多流行的加密货币来说， 728 | 为基于预订的材料进行支付要么无法接受，要么太过繁琐。Metronome 预订功能可以解决这一问题。 729 | 730 | 731 | 732 | 733 | 734 | 735 | 736 | 737 | 738 | 739 | 740 | 741 | 742 | 743 | 744 | 745 | 747 | 748 | 749 | 750 | 751 | 752 | 753 | 754 | 755 | 756 | 757 | 758 | 759 | 760 | 761 | 762 | 763 | 764 | 765 |
function subscribe(uint _startTime, uint _payPerWeek, address _recipient) public returns (bool)预订某人，即授权他们提取每周付款 _startTime 是预订开始的时间 _payPerWeek 是每周应付代币，包括小数 _recipient 是可以提取代币的人
function cancelSubscription(address _recipient) public returns (bool)取消预订 _recipient 是您退订的人
function getSubscription(address _owner, address _recipient) public constant returns (uint startTime, uint payPerWeek, uint lastWithdrawTime)取得预订信息 _owner 支付，_recipient 是取得预订的人 返回以下信息，startTime 是预订开始的时间 payPerWeek 是接收者每周可以提取的金额 lastWithdrawTime 是接收者上一次提取时间
function subWithdraw(address _owner) public transferable returns (bool)从向您预订的人那里提款，返回成功 746 | _owner 是您的订户
function multiSubWithdraw(address[] _owners) public returns (uint)立即从一群订户（所有者）提取资金。返回成功提取的次数。
function multiSubWithdrawFor(address[] _owners, address[] _recipients) public returns (uint)从给定订户（所有者）提取资金给各自的接收者。返回成功提取的次数。
event LogSubscription(address indexed subscriber, address indexed subscribesTo)为新用户预订发出
event LogCancelSubscription(address indexed subscriber, address indexed subscribesTo)当用户取消预订时发出
766 | 767 | ### 拍卖 API 768 | 769 | 770 | 771 | 772 | 773 | 774 | 775 | 776 | 777 | 778 | 779 | 780 | 781 | 782 | 783 | 784 | 785 | 786 | 787 | 788 | 789 | 790 | 791 | 792 | 793 | 794 | 795 | 796 | 797 | 798 | 799 | 800 | 801 | 802 | 803 | 804 | 805 | 806 | 807 | 808 | 809 | 810 | 811 | 812 | 813 | 814 | 815 | 816 | 817 | 818 | 819 | 820 | 821 | 822 | 823 | 824 | 825 | 826 | 827 | 828 | 829 | 830 | 831 | 832 | 833 | 834 | 835 | 836 | 837 | 838 |
Function () payable标准回退函数；发送 ETH，立即取得 MET 代币
function whatWouldPurchaseDo(uint _wei, uint _timestamp) public constant returns (uint weiPerToken, uint tokens, uint refund)告诉用户在时间 _timestamp 购买的结果是什么，_wei 是要发送的 ETH 的数量，_timestamp 是预期拍卖的时间戳。weiPerToken 是结果价格，tokens 是将返回的代币数量，refund 是用户将得到的 ETH 退款（如果拍卖在本次购买中售罄）
function isRunning() public constant returns (bool) 如果拍卖系统已启动，则为 True
function currentTick() public view returns(uint)调用 whichTick 获取当前块的时间戳
function currentAuction() public view returns(uint)调用 whichAuction(currentTick())
function whichTick(uint t) public view returns(uint)返回给定时间戳 t 的拍卖时间点，自开端时间起
function whichAuction(uint t) public view returns(uint)返回给定拍卖时间点 t 的拍卖实例
function heartbeat() public view returns (bytes8 chain,address auctionAddr,address convertAddr,address tokenAddr,uint minting,uint totalMet,uint proceedsBal,uint currTick, uint currAuction,uint nextAuctionGMT,uint genesisGMT,uint currentAuctionPrice,uint dailyMintable,uint _lastPurchasePrice)返回当前拍卖的统计数据
function mintInitialSupply(uint[] _founders, address _token, address _proceeds, address _autonomousConverter) public onlyOwner returns (bool)在初始部署期间调用，以便为创始人铸造初始供应。此函数仅与所有者有关。
function initAuctions(uint _startTime, uint _minimumPrice, uint _startingPrice, uint _timeScale) public onlyOwner returns (bool)在初始部署期间调用设置拍卖开始时间参数。此函数仅与所有者有关。
function stopEverything() public onlyOwner暂停当前拍卖的仅与所有者有关的函数。
function isInitialAuctionEnded() public view returns (bool)如果 7 天已过或者所有代币都在初始拍卖中售罄，则为 True
function globalMetSupply() public view returns (uint)截至当前拍卖的可用供应总数
function globalDailySupply() public view returns (uint)当前每日拍卖的可用 MET 代币总数
function currentPrice() public constant returns (uint weiPerToken)每日拍卖的当前价格
event LogAuctionFundsIn(uint amount)当拍卖合约取得资金时发出
839 | 840 | Metronome 收益合约 841 | --------------------------- 842 | 843 | ### 收益合约 API 844 | 845 | | event LogProceedsIn(address indexed from, uint value) | 当收益合约取得资金时发出 | 846 | | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------- | 847 | | event LogClosedAuction(address indexed from, uint value) | 当收益将资金投入到 AutonomousConverter 时发出 | 848 | | function () public payable | 处理收益资金来源 | 849 | | function initProceeds(address \_autonomousConverter, address \_auction) public onlyOwner | 在初始部署期间调用。此函数仅与所有者有关。 | 850 | | function closeAuction() public | 在拍卖结束时向 AutonomousConverter 发送资金 | 851 | 852 | Metronome 自治转换合约 853 | --------------------------------------- 854 | 855 | ### 自治转换合约 API 856 | 857 | 858 | 859 | 860 | 861 | 862 | 863 | 864 | 865 | 866 | 867 | 868 | 869 | 870 | 871 | 872 | 873 | 874 | 875 | 876 | 877 | 878 | 879 | 881 | 882 | 883 | 884 | 887 | 888 | 889 | 890 | 892 | 893 | 894 | 895 | 897 | 898 | 899 | 900 | 901 | 902 | 903 | 904 | 905 | 906 | 907 | 908 | 909 | 910 | 911 |
function () public payable处理 AutonomousConverter 资金来源
function init(address _reserveToken, address _smartToken, address _proceeds, address _auctions) public payable 在初始部署期间调用。此函数仅与所有者有关。
function getMetBalance() public view returns (uint)在合约内显示 MET 余额
function getEthBalance() public view returns (uint) 在合约内显示 ETH 余额
function convertEthToMet(uint _mintReturn) public payable returns (uint returnedMet) 将 ETH 转换成 MET。如果返回的 MET 小于 minReturn，则丢弃。返回 880 | MET 的数量。
function convertMetToEth(uint _amount, uint _mintReturn) public returns (uint returnedEth) 将 MET 转换成 ETH。如果返回的 ETH 885 | 小于 minReturn，则丢弃。返回 ETH 的数量。调用者首先需要批准 AC 进行 886 | 转移。
function getMetForEthResult(uint _depositAmount) public view returns (uint256)返回用户将由 891 | 给定的 ETH 金额得到多少 MET。
function getEthForMetResult(uint _depositAmount) public view returns (uint256) 返回用户将由 896 | 给定的 MET 金额得到多少
event LogFundsIn(address indexed from, uint value)当 AutonomousConvert 取得资金时发出
event ConvertEthToMet(address indexed from, uint eth, uint met)当发生从 ETH 到 MET 的转换时发出。
event ConvertMetToEth(address indexed from, uint eth, uint met)当发生从 MET 到 ETH 的转换时发出。
912 | 913 | TokenLocker 914 | ----------- 915 | 916 | ### TokenLocker API 917 | 918 | | event Withdrawn(address indexed who, uint amount) | 对所有提取发出 | 919 | | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | 920 | | event Deposited(address indexed who, uint amount) | 对所有存款发出 | 921 | | function lockTokenLocker() public onlyAuction | 锁定 tokenLocker。调用此函数将导致 tokenLocker 的 postLock 阶段。不允许再存款。在此阶段允许提取代币。此函数仅与拍卖有关。 | 922 | | function deposit (address beneficiary, uint amount) public onlyAuction preLock | 将资金存入存储器。仅允许在 preLock 阶段进行存款。 | 923 | | function withdraw() public onlyOwner postLock | 资金提取只能在 postLock 阶段进行。此函数仅与所有者有关。 | 924 | 925 | TokenPorter 926 | ----------- 927 | 928 | ### TokenPorter API 929 | 930 | | event ExportReceiptLog(bytes8 destinationChain, address indexed destinationMetronomeAddr, address indexed destinationRecipientAddr, uint amountToBurn, bytes extraData, uint currentTick, uint indexed burnSequence, bytes32 currentBurnHash, bytes32 prevBurnHash, uint dailyMintable, uint\[\] supplyOnAllChains, uint genesisTime) | 在导出请求期间发出 | 931 | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | 932 | | function addDestinationChain(bytes8 \_chainName, address \_contractAddress) public onlyOwner returns (bool) | 添加链作为认可链用于 metronome 导出。此函数仅与所有者有关。 | 933 | | function removeDestinationChain(bytes8 \_chainName) public onlyOwner returns (bool) | 从认可链中移除链以用于 metronome 导出。此函数仅与所有者有关。 | 934 | | function claimReceivables(address\[\] recipients) public returns (uint) | 此函数的调用方是正在执行 metronome 导入以记录目标合约中 metronome 铸造的目标合约。 | 935 | | function export(bytes8 \_destChain, address \_destMetronomeAddr, address \_destRecipAddr, uint \_amount, bytes \_extraData) public returns (bool) | 导出用户账户以导入另一个区块链 | 936 | 937 | 合约条款术语表 938 | ========================== 939 | 940 | - **自治转换合约** 智能合约，允许人们用 ETH 交换 MET，或者将 ETH 转换成 MET。 941 | 942 | - **自治收益供应商** Metronome 收益合约与自治转换合约。 943 | 944 | - **常量** 包含一些常用常量，如 DECIMALS。 945 | 946 | - **每日总量批次** 导致代币生态系统每天都会增加新铸造 MET 的降价拍卖。 947 | 948 | - **EVM** 代表以太坊虚拟机。[^44] 949 | 950 | - **定点\_数学** 实施定点运算，包括加、减、乘、除、平方、平方根，包括溢出保护。对于二元函数，它会假定两个输入值具有相同的小数位数。 951 | 952 | - **公式** 使用定点数学函数运算核心 Bancor 公式。公式具有无状态性，所有变量都只能作为参数。 953 | 954 | - **Metronome** 主要拍卖合约。 955 | 956 | - **迁移系统** Truffle 迁移能力的一部分。 957 | 958 | - **储备代币** 实施 MET。赋予自治转换合约转移代币的权利（响应交易事件）。 959 | 960 | - **收益合约** 接受来自 Metronome 的 ETH，每 24 小时将其余额的 0.25% 转让给自治转换合约。 961 | 962 | - **智能代币** 自治转换合约发行的代币在通过其合约进行 MET 和 ETH 转换（反之亦然）时充当中介。该过程自发进行，不会向用户公开。 963 | 964 | - **代币** 买方购买的 MET 代币。 965 | 966 | 附录 A 967 | ========== 968 | 969 | 确认和免责声明 970 | 971 | 购买、使用和/或使用 METRONOME 代币，即表示您明确确认并承担以下风险。 972 | 973 | 1. **[买方确认]**。作为 Metronome 代币（以下简称“MET”）的买方（以下简称“买方”或“您”），您确认以下几点： 974 | 975 | a. MET 是[not]作为证券或 976 | 其他任何形式的投资产品构建或销售的。MET 尚未按照 977 | 美国证券交易委员会 1933 年修订的 978 | 《证券法》或 979 | 任何国家/地区证券法 980 | 或任何其他管辖区的任何类似法律注册，也不适用于 981 | 这些法律规定的豁免。因此，用户手册中的信息 982 | 不能作为 983 | 投资决策的根据，也不构成任何 984 | 具体建议。MET 的使用、销售或 985 | 处置受用户 986 | 手册中的规定的限制。购买 MET 即表示买方 987 | 遵守用户手册的所有要求以及 988 | 包括美国联邦、州在内的所有司法管辖权区颁布的所有法律 989 | 或当地法律。MET 的创造者明确声明对 990 | 直接或间接造成的任何直接或间接损失或 991 | 损害不承担任何责任， 992 | 包括因下列各项导致的损失或损害：(i) 依赖用户 993 | 手册或其他文件中包含的信息，(ii) 此类信息的任何错误、遗漏 994 | 或不准确，或 (iii) 此类信息导致的 995 | 任何行为； 996 | 997 | b. 本文件尚未登记， 998 | 将不会作为新加坡金融管理局的招股说明书登记，且不是 999 | 《证券与期货法》(SFA) 中规定的招股说明书 1000 | （新加坡第 289 章）（“**SFA**”）。因此，SFA 关于 1001 | 招股说明书的法定责任 1002 | 不适用； 1003 | 1004 | c. 您不会使用 MET 或 Metronome 来创建由美国商品期货交易委员会 1005 | 监管的产品，包括 1006 | 期货合约、掉期交易或零售商品 1007 | 交易。您还确认购买 MET 不用于 1008 | 任何形式的期权 1009 | 或掉期交易； 1010 | 1011 | d. 您了解与 1012 | 加密代币、代币存储机制（如加密 1013 | 钱包）和区块链技术相关的技术和业务问题，了解 MET 并 1014 | 知晓使用、购买 1015 | 和/或处理 MET 的风险与后果； 1016 | 1017 | e. 您已获得足够的有关 MET 的信息来 1018 | 做出明智购买 MET 的决定，并且不依赖 1019 | 用户手册中提供的任何信息 1020 | 来做出购买 MET 的决定； 1021 | 1022 | f. 您知道 MET 只授予在 1023 | 用户手册中设想的 MET 的权利。MET 不授予任何形式的 1024 | 其他权利，包括但不限于实体所有权、 1025 | 分配权、赎回权、清算权、专利权 1026 | （包括任何形式的知识产权）、财务 1027 | 或法律权限； 1028 | 1029 | g. 您只是按照用户手册中设想的 MET 1030 | 购买 MET，并知晓 1031 | 与 MET 相关的商业风险。您不会出于其他目的 1032 | 购买 MET，包括但不限于任何 1033 | 投资、投机或财务目的； 1034 | 1035 | h. 您购买 MET 的行为符合您所在司法管辖区的 1036 | 适用法律和法规，包括但不限于 1037 | (i) 购买 MET 的合法能力和 1038 | 任何要求或限制，(ii) 适用于 1039 | 此类购买的任何外汇或监管限制，以及 (iii) 任何 1040 | 可能需要获得的政府或其他部门的批准； 1041 | 1042 | i. 您全权承担您购买或使用 MET 1043 | 产生的任何适税义务； 1044 | 1045 | j. 如果您代表实体购买 MET，您有权 1046 | 代表实体 1047 | 同意这些确认和免责声明； 1048 | 1049 | k. 您不是 (i) 适用法律、法令、条例、条约或行政法案 1050 | 禁止接受 MET 交付的地区的 1051 | 公民或居民， 1052 | (ii) 位于受联合国、欧盟、美国或其他主权国家/地区 1053 | 制裁或禁运的地区的 1054 | 公民或居民，或 (iii) 美国商务部的被拒人士或实体名单、 1055 | 美国财政部特别指定的国民或被冻结人员名单、 1056 | 美国国务院禁止的缔约方名单、 1057 | 类似的受限制人员条例 1058 | 或任何其他适用主权国家/地区的名单、 1059 | 或任何前述或后续规章限制的 1060 | 任何个人 1061 | 或受实体雇用或与实体有关的个人。您同意 1062 | 若您居住的国家/地区或其他情况发生变化， 1063 | 导致以上确认不再准确，您将 1064 | 立即停止使用 MET； 1065 | 1066 | l. MET 的价值取决于人们是否接受它 1067 | 作为加密货币使用， 1068 | 以及它被用于支付商品和服务的程度。需求不足可能使 MET 1069 | 难以用于支付货物和服务，这往往会 1070 | 降低 MET 的价值。同样，如果不采用 MET， 1071 | 价值通常也会降低。此外， 1072 | 近期内仍存在对加密货币和代币销售的 1073 | 重大监管风险， 1074 | 这可能会大大降低 MET 的价值； 1075 | 1076 | m. MET 的价值应主要取决于 1077 | 使用 MET 作为支付商品和服务的加密货币 1078 | 的普遍价值； 1079 | 1080 | n. MET 作为加密货币， 1081 | 由于竞争和市场条件影响了总体供需， 1082 | MET 的价格会发生波动。这些条件超出了任何特定方 1083 | 或 MET 持有者的控制范围。MET 1084 | 在使用或交换时的价值 1085 | 可能低于购买时的价格； 1086 | 1087 | o. 定期、自主、独立发布新的 MET 1088 | 旨在稳定 MET 价格， 1089 | 以实现 Metronome 生态系统服务的内在价值，但 1090 | 无法保证此类 MET 发布， 1091 | 并且可能会以任何价格为自己的账户购买和销售 MET； 1092 | 1093 | p. 出售 MET 并不会限制 1094 | Metronome 参与其他项目、运营其他网络 1095 | 或发行可能与 MET 竞争的其他代币的权力； 1096 | 1097 | q. 不承诺 1098 | MET 的未来表现或价值，包括不对内在价值、 1099 | 继续付款进行任何承诺， 1100 | 也不保证 MET 将保留任何特定价值；并且 1101 | 1102 | r. Metronome 创始人对于如何使用自己的 1103 | MET 销售收益没有任何条件。 1104 | 1105 | 2. **[确认某些风险]**。您确认 1106 | MET 存在以下风险，并同意 1107 | 您明确承担这些风险： 1108 | 1109 | s. ***MET 的自治性***。MET 自治运营， 1110 | 没有任何一方能够影响或控制 1111 | MET 的运营。MET 的自治性可能 1112 | 会在未来造成风险，包括您在发行 MET 或购买时 1113 | 无法预见的风险。 1114 | 1115 | t. ***由于丢失私钥、 1116 | 保管错误或买方错误而失去 MET 访问权限的风险。*** 私钥或 1117 | 私钥组合对于 1118 | 控制和处理存储在数字钱包或保险库中的 MET 必不可少。因此，丢失 1119 | 与数字钱包或存储 MET 的保险库相关的必要私钥 1120 | 将导致该 MET 的丢失。此外， 1121 | 任何获得此类私钥的第三方， 1122 | 包括通过访问您使用的托管钱包服务的登录凭据， 1123 | 都可能会盗用 MET。由您选择取得和存储 MET 的 1124 | 数字钱包或保险库 1125 | 所引起的与之相关的任何错误或故障， 1126 | 包括您自己未能妥善维护或使用此类数字钱包或保险库， 1127 | 也可能导致 MET 丢失。 1128 | 此外，如果您没有严格遵守 1129 | 购买和取得 MET 所规定的程序，例如， 1130 | 如果您提供了错误地址，则可能会导致 MET 丢失。 1131 | 1132 | u. ***与区块链协议相关的风险。*** 任何 1133 | 故障、分解或放弃 MET 赖以运行的区块链协议 1134 | 都可能对 MET 1135 | 产生重大不利影响。此外，密码学或技术方面的进步 1136 | 可能会给 MET 带来风险， 1137 | 因为这会使 1138 | 支持区块链协议的密码协商机制无效。 1139 | 1140 | v. ***挖矿攻击的风险。*** MET 在区块链验证 MET 交易的过程中 1141 | 容易受到矿工的攻击， 1142 | 包括但不限于双重支付攻击、 1143 | 多数挖矿动力攻击、选择性延迟或交易审查 1144 | 以及自私挖矿攻击。任何成功的攻击 1145 | 都会给 MET 带来风险，包括但不限于 1146 | 涉及 MET 交易的精确执行和记录。 1147 | 1148 | w. ***黑客攻击和安全弱点的风险。*** 黑客或其他 1149 | 恶意团体或组织可能尝试以各种方式干扰 1150 | MET，包括但不限于恶意 1151 | 软件攻击、拒绝服务攻击、基于共识的攻击、 1152 | SybIL 攻击、欺骗。此外，由于 MET 1153 | 基于开源软件而构建，因此第三方 1154 | 可能有意或无意地将弱点 1155 | 引入新 MET 实施的核心基础设施，这 1156 | 可能会对 MET 产生不利影响。黑客或其他恶意团体 1157 | 或组织也可能试图访问私钥， 1158 | 钱包、保险库中的其他访问凭据， 1159 | 或用于取得和保留 MET 的其他存储机制。 1160 | 1161 | x. ***与 MET 市场相关的风险。***如果 MET 的二次交易 1162 | 由第三方交易所促成， 1163 | 则此类交易所可能相对较新，且很少受 1164 | 监管监督或根本不受监督，因此更容易受到欺诈或 1165 | 操纵。此外，就第三方确实 1166 | 将外汇交易价值归于 MET（例如，以 1167 | 数字或法定货币计价）而言，此价值可能极易 1168 | 波动，并可能减少至零。 1169 | 1170 | y. ***无保险的损失风险。***与某些银行账户 1171 | 或其他金融机构的账户不同，MET 没有保险。 1172 | 因此，在效用价值损失的情况下，没有 1173 | 公共保险公司或私人保险为您提供追索权。 1174 | 1175 | z. ***与不确定的法规和执法行动 1176 | 相关的风险。*** 在许多司法管辖区，MET 和分布式分类账技术的监管状况 1177 | 尚不清楚或未得到解决。对于包括 MET 在内 1178 | 的这类技术及应用， 1179 | 很难预测监管机构如何或是否 1180 | 应用现有法规。同样，很难 1181 | 预测立法机构或监管机构 1182 | 如何或是否修改影响分布式分类账技术及其应用（包括 MET） 1183 | 的法律法规。 1184 | 监管措施可能以各种方式对 MET 产生不利影响， 1185 | 包括仅出于说明目的，通过 1186 | 确定 MET 的购买、销售和交付 1187 | 构成非法活动，或 MET 是需要就这些手段 1188 | 进行注册或许可的受管制工具， 1189 | 或者在购买、销售和交付过程中 1190 | 涉及的部分或所有各方。 1191 | 1192 | a. ***税收带来的风险。*** MET 的税务特征 1193 | 不确定，可能导致不利的税务后果， 1194 | 包括预扣税、所得税和税务申报 1195 | 要求的变化。您必须寻求与 MET 有关的 1196 | 税务建议。 1197 | 1198 | b. ***技术风险***MET 代表了一项尚未得到充分证明的 1199 | 新兴技术新功能。随着 1200 | 技术的成熟，新功能可能会极大地改变 1201 | MET 的有用性或者使用或销售 MET 的能力。 1202 | 1203 | c. ***意外风险。*** 除了本附录所包含的风险之外， 1204 | 还存在与 1205 | 购买、持有和使用 MET 相关的其他风险，包括 1206 | 意外风险。此类风险可能会进一步发生变化 1207 | 或演变成为本附录提到的 1208 | 风险组合。 1209 | 1210 | 1211 | 1212 | 1. **[免责声明]**。每个 MET 均在“现状”和“现有”的基础上进行销售，不含任何形式的担保，包括但不限于对适销性、特定用途的适用性、所有权或非侵权的暗示保证。 1213 | 1214 | [^1]: 1215 | 1216 | [^2]: 1217 | 1218 | [^3]: 1219 | 1220 | [^4]: 1221 | 1222 | [^5]: 1223 | 1224 | [^6]: 1225 | 1226 | [^7]: Tsiang, S.C., Journal of Money, Credit and Banking, I(1969), pp. 1227 | 266--80 \"A Critical Note on the Optimum Supply of Money\" 1228 | 1229 | [^8]: 1230 | 1231 | [^9]: 1232 | 1233 | [^10]: 1234 | 1235 | [^11]: 1236 | 1237 | [^12]: 1238 | 1239 | [^13]: 1240 | 1241 | [^14]: 1242 | 1243 | [^15]: 来源：coinmarketcap, coinbase, blockchain.info, Federal Reserve Bank of St Louis 1244 | 1245 | [^16]: 1246 | 1247 | [^17]: Mishra, Debasis, and David C. Parkes. "Multi-Item Vickrey-Dutch 1248 | Auctions." Games and Economic Behavior, vol. 66, no. 1, 2009, pp. 1249 | 326--347., doi:10.1016/j.geb.2008.04.007. 1250 | 1251 | [^18]: 1252 | 1253 | [^19]: 来源：coinmarketcap.com, coinbase, blockchain.info 1254 | 1255 | [^20]: 1256 | 1257 | [^21]: 1258 | 1259 | [^22]: 1260 | 1261 | [^23]: 1262 | 1263 | [^24]: 来源：coinmarketcap.com, coinbase, blockchain.info 1264 | 1265 | [^25]: 1266 | 1267 | [^26]: 1268 | 1269 | [^27]: 1270 | 1271 | [^28]: 1272 | 1273 | [^29]: 1274 | 1275 | [^30]: 1276 | 1277 | [^31]: 1278 | 1279 | [^32]: 1280 | 1281 | [^33]: 1282 | 1283 | [^34]: 1284 | 1285 | [^35]: 1286 | 1287 | [^36]: 1288 | 1289 | [^37]: 1290 | 1291 | [^38]: 1292 | 1293 | [^39]: 1294 | 1295 | [^40]: 1296 | 1297 | [^41]: 1298 | 1299 | [^42]: 1300 | 1301 | [^43]: 1302 | 1303 | [^44]: 1304 | 1305 | -------------------------------------------------------------------------------- /validatordocument/img/Figure-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/validatordocument/img/Figure-1.png -------------------------------------------------------------------------------- /validatordocument/img/Figure-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/validatordocument/img/Figure-2.png -------------------------------------------------------------------------------- /validatordocument/img/Figure-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/validatordocument/img/Figure-3.png -------------------------------------------------------------------------------- /validatordocument/img/Figure-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/validatordocument/img/Figure-4.png -------------------------------------------------------------------------------- /validatordocument/img/Figure-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/autonomoussoftware/documentation/c073d4e47065ef92a25f562ab99a68120c8d36d7/validatordocument/img/Figure-5.png -------------------------------------------------------------------------------- /validatordocument/validatordocument.md: -------------------------------------------------------------------------------- 1 | # Metronome Cross-chain Token Transfer 2 | v0.915 (Last updated 06.24.2019) 3 | ## Introduction 4 | 5 | One of the key features that helps ensure durability and resilience of Metronome tokens is the ability to move MET from one blockchain to another. Unlike almost all other digital tokens, Metronome helps owners avoid risk by provably moving the same asset from blockchain A to blockchain B. The process of moving Metronome tokens across blockchains is known as **import** and **export**, and this document provides engineers and the community with significant additional detail about this key feature. 6 | 7 | The Metronome import and export algorithms enable transfer of MET tokens from one set of Metronome smart contracts to another set of Metronome smart contracts (usually) hosted on a different blockchain. Exporting from a contract provably removes the MET tokens from the origin-chain, and importing to a contract provably adds the MET tokens to the destination chain. The Metronome protocol ensures a single global money supply remains intact. 8 | 9 | Below, we first introduce terminology used throughout this document. Next we set out our requirements and challenges involved. Finally, we discuss individual component designs the proposal for token transfer that offers good tradeoffs in terms of scalability, security, and decentralization. 10 | 11 | This document, particularly surrounding phase 2 and 3 of validation, is a living, collaborative document. We encourage community members to read this documentation and provide feedback, suggestions, and edits in the form of GitHub issues. The multi-phase validation plan follows the wider goal of Metronome, where this project aims to provide ever-increasing amounts of decentralization, and an overall sustainable autonomous economy. 12 | 13 | ## Definitions 14 | 15 | A **Validator** is off-chain software running on distributed nodes, maintained by a publicly known entity, which exists in order to propagate an event from one blockchain to another. Validators are responsible for observing a blockchain for events, validating cross chain transactions (as described below), and voting on the validity of that event. Initially, there will be about n validators (with the goal of 5) but eventually we must allow any trusted entity to run a validator in order to encourage a more decentralized MET token transfer process, with the need for validators fading in subsequent phases. 16 | 17 | A **Source chain** is a blockchain running Metronome smart contracts from which a user wishes to transfer MET tokens. The target chain of the transfer is referred to as the **Destination chain**. 18 | 19 | An **Export event** occurs on the Source chain when a user wishes to initiate a MET token transfer. It is equivalent to a burn event, where the desired number of tokens have been removed from that chain’s supply. Corresponding to each Export event is an **Import event** on the Destination chain where the same number of previously burned tokens are minted onto the destination chain. 20 | 21 | Before emitting an Export event, the Source chain creates and stores the **burn transaction**, capturing all details of the burn, including the previous burn transaction. In this way, each chain maintains a list of all burn transactions that have originated from that chain, regardless of what their Destination chain will be. Also, each burn transaction hash depends on the previous burn transaction hash. By definition, the very first burn transaction on a given chain has no previous burn transaction, so uses the value of “0” for its hash. 22 | 23 | A **Merkle tree** is built up by recursively hashing adjacent pairs of data from some given sequence. At the top of the tree is the **root hash**, which indirectly depends on every element in the tree. No data can be changed in the tree without affecting the **root hash**. An element can be proven to be in the tree by performing a **Merkle proof**, which consists of providing an element and its **Merkle path** to the root. The Metronome transfer strategy utilizes the creation of a Merkle tree from burn transactions. 24 | 25 | A **lily pad** is an informal term for a single interconnected set of deployed Metronome smart contracts. It is a single data domain against which MET token import and export occurs. Because two lily pads may be deployed on the same blockchain, it is more technically accurate to refer to Metronome import/export as transferring MET between lily pads. Each lilypad contains and manages a separate ledger each keeping track of its share of the global MET supply. 26 | 27 | ## Merkle Tree Construction and Path Verification 28 | 29 | Let us show an example of building a Merkle tree from a list of eight values, numbered B1 to B8. First we hash each value individually, producing H1 to H8. 30 | 31 | The tree is then built from the bottom up, where we progressively hash together adjacent elements to form parents in the tree that make up the higher levels. 32 | 33 | Combining adjacent elements gives us half the number of values: 34 | - H1..2 = hash(H1, H2) 35 | - H3..4 = hash(H3, H4) 36 | - H5..6 = hash(H5, H6) 37 | - H7..8 = hash(H7, H8) 38 | 39 | We next move up one level, again resulting in half the number of values: 40 | - H1..4 = hash(H1..2, H3..4) 41 | - H5..8 = hash(H5..6, H7..8) 42 | 43 | And finally we produce the root of the Merkle tree: 44 | - H1..8 = hash(H1..4, H5..8) 45 | 46 | ![Figure 1](img/Figure-1.png) 47 | 48 | The true utility of a Merkle tree lies in the computationally efficient way of proving an element is in the tree. 49 | 50 | Assume you are given the root of the tree, H1..8, as derived above. You can prove that some element, say B4, is in the tree by also providing what is referred to as the Merkle path. The path is made up of the siblings of the nodes reached while going up the tree to the root. 51 | 52 | ![Figure 2](img/Figure-2.png) 53 | 54 | For the H4 element, the corresponding path would be: H3, H1..2, and H5..8. 55 | 56 | The sequence of operations you would do to validate the path would be: 57 | - H4 = hash(B4) 58 | - H3..4 = hash(H3, H4) 59 | - H1..4 = hash(H1..2, H3..4) 60 | - H1..8 = hash(H1..4, H5..8) 61 | 62 | The path is validated if the final hash value arrived from the path matches the H1..8 previously given. 63 | 64 | Note that there are other implementation details, such as how to handle a number of blocks that are not a power of two or the specification of the ordering of the arguments to the hash function. These details are out of scope of this document. 65 | 66 | ## Requirements 67 | 68 | The global supply of MET tokens must be limited and predictable at all times. The supply must never exceed the 10,000,000 initial supply plus the present sum of the daily minted tokens, which are minted as the greater of 2,880 tokens or the amount required to achieve an annual rate of 2% of the outstanding MET in circulation. 69 | 70 | One of the original principles in blockchain design was to prevent double spending. Thus, during the process of transferring MET tokens from one chain to another, we must guard against a single Export resulting in multiple Imports. Conversely, if we design for the ability to cancel an Export event we must not allow an Export to be reversed and the corresponding Import to proceed. 71 | 72 | We must also design how to handle blockchain forks, as this could lead to an artificial increase in the global supply and/or double spending. 73 | 74 | As we wish to grow the already functional Metronome ecosystem, we will need the ability to onboard new blockchains. This in turn will require us to onboard new validators. 75 | 76 | In the early phases (phase 1 especially), we use the ability to remove validators and chains from the system. Like other multi-signature/multi-party signing systems, cases such as validator retirement and key revocation must be handled. There are also cases where -- most notably in phase 1 -- where a chain may be removed, when a chain may unexpectedly start violating the Metronome protocol (ie. bitcoin-like consensus behavior), or a chain becomes not economically worth validating (blockchain tx fees skyrocket to the point of economic unsustainability). 77 | 78 | Our last requirement is perhaps the most important: Transfers must be cryptographically provable and transparent. 79 | 80 | For completeness, we will mention a few issues that we are not setting out to solve. There is no restriction that both the source and destination address used in a transfer belong to the same user, thus we allow transfers to any address on the Destination chain. This creates a common network carrier style policy that aims to be content and address neutral. There is no restriction that Import events are processed or accepted in the same order as the corresponding Export events. 81 | 82 | ## Three Phase Approach 83 | 84 | In order to ensure security and usability of Metronome’s cross-chain features, there will be three phases of cross chain rollout. Each subsequent phase will further decentralize the process for completing cross-chain moves. 85 | 86 | **Phase 1** - Federated Network of Validators 87 | 88 | In phase 1, a small, federated network of validators operates in a multi-signature, multi-party approach to validate import/export transactions follow the Metronome protocol. MET owners may export at any time. On the import side, a quorum of validators approves a set of import transactions submitted by users. A quorum of validators will add and remove Metronome-available chains and other validators. The goal of Phase 1 quorum is to have 5 validators at the launch of the 2nd Metronome chain (and thus, the launch of the first Metronome import/export). 89 | 90 | In the event of a chain fork, the quorum of validators will choose which side of a fork is The Real Metronome. 91 | 92 | **Phase 2** - Chain Attestors and stake weighting 93 | 94 | Phase 2 seeks to decentralize and move away from validators. For each blockchain, Metronome will look to *chain oracles* that provide a very specific piece of data: What is the Official Timeline for a particular currency? 95 | 96 | Take for example Ethereum (ETH) chain. In the event of an Ethereum hard fork, the Metronome system would look to *ethereum community* oracles to answer the question of Latest Block Hash. The Metronome system, on Ethereum, would automatically follow the side of a hard fork that the Ethereum community follows. 97 | 98 | This system is replicated for each blockchain supported, such as Ethereum Classic (ETC), Qtum and Rootstock on Bitcoin (RSK/BTC). ETC would have its own, independent set of *community oracles* that answer the question of Latest Block Hash. In the event of an ETC fork, the Metronome system would use the ETC community oracles as the source of truth. 99 | 100 | The goal is the *automate* the choosing of hard fork sides, automatically ingesting and following the community choice for each blockchain. 101 | 102 | Finally, as a global check on shenanigans via minority chains and attack-style hard forks, the percentage of total Metronome tokens on a particular chain shall have that level of percentage global weight, in the event of a discrepancy in the Metronome consensus protocol between two versions of the MET global supply timeline. 103 | 104 | **Phase 3** - Fully autonomous, stake-weighted cross chain transfers 105 | 106 | Phase 3 of cross-chain validation provides a fully decentralized end state. The model mirrors that of the original Bitcoin blockchain, a full consensus protocol. This model includes 107 | 1. A **node**. In MET phase 3, each lily pad may be considered like a single Bitcoin node. 108 | 2. A **blockchain**. In MET phase 3, each lily pad maintains its own independent copy of the history of all MET cross-chain transfers. 109 | 3. A **transaction**. In MET phase 3, each user-generated import may be considered like a single unconfirmed Bitcoin transaction. An import is considered confirmed after 24 blocks (24 hours). 110 | 4. A **block**. In MET phase 3, a block may be generated once per hour, on a stake-weighted basis (total stake weight of entire lily pad). This block is shared by users desiring imports to each lily pad. 111 | 5. **Consensus protocol** is Bitcoin design, with proof-of-stake modification. We call this **APS**, Autonomous Proof of Stake, because it is different from both POS and DPOS. In MET phase 3, each lily pad is a stake-weighted autonomous actor. 112 | 113 | This is possibly the first *cross-blockchain blockchain*. Each lily pad -- each set of smart contracts -- uses a Bitcoin-style consensus protocol, with Proof-of-Stake modification to determine the outcome of hard forks. This consensus protocol *automatically* chooses one side of a hard fork over another. 114 | 115 | ## Challenges 116 | 117 | ### Forking 118 | 119 | Forks may occur under different circumstances. Temporary forks occur frequently when multiple nodes mine the next block, though these forks are quickly resolved as the longest chain amongst peers wins. By requiring that the validators not react to an Export event until it is at some minimal block height, which may vary across chains, the chance of a validator voting on and propagating a soon to be abandoned block should be minimal. For instance, on Ethereum community members suggest a minimal block height of anywhere between 5 and 500 based on the desired level of security (https://ethereum.stackexchange.com/questions/319/what-number-of-confirmations-is-considered-secure-in-ethereum). 120 | 121 | A contentious hard fork, on the other hand, occurs when some portion of the community has decided to diverge the blockchain client and essentially create a new, independent chain. The resolution of a contentious hard fork will require human intervention. It must be decided by the Metronome system and/or community which fork will be kept. 122 | 123 | As noted above, there will be three phases of the validator network – going from a compromise, federated model to increasingly decentralized with each additional phase. These phases govern how to handle things like chain addition, removal, and fork choices. 124 | 125 | **Phase 1** - Federated Network of Validators 126 | 127 | In phase 1, the federated validator network will consider the technical, security, and community characteristics of both sides of the contentious fork. Following deliberation of these considerations, a quorum of validators will eventually “bless” one chain to be viewed as valid by the Metronome network. 128 | 129 | **Phase 2** - Chain Attestors 130 | 131 | Phase 2 forked chain election will utilize the knowledge and community sentiment of their specific chain. For example, suppose that chain A is forking. Chain A’s foundation, or other consortium of developers, merchants, and other community members will choose which side the Real Ethereum or the Real Ethereum Classic etc. The Metronome system will follow that choice. New forks do not create new airdrops of MET tokens. 132 | 133 | **Phase 3** - Stake-weighted Blockchain of Blockchains 134 | 135 | Phase 3 of cross-chain validation will use a blockchain of blockchains, described above, to validate headers, but will choose the side of a contentious fork based off the weight of that particular chain(s)’s portion of the global Metronome supply. The side with more of that supply will become the valid chain. 136 | 137 | Once consensus is achieved, only one fork -- and the MET therein -- would be made valid in the Metronome ecosystem via the validation process as described (since this new fork is effectively a new chain, see the “Adding and Removing Chains” section). This blocks any further transfer of MET tokens to or from the new chain, as those tokens on the losing side of the fork are no longer Metronome. 138 | 139 | If the Metronome community later decides to support this newly forked chain, it would be onboarded just as any new lily pad would be. A new set of Metronome contracts would be deployed, which would not share any history with the previously deployed contracts on that chain. 140 | 141 | ### Validator Front-running 142 | 143 | It is possible that a miner can observe pending transactions, and act in the market with that knowledge. It is possible that miners may block certain cross-chain transactions for a specific blockchain. 144 | 145 | In phase 1, validators introduce similar risks. validators see import/export transactions immediately, and may act on that knowledge in the market, or on the transaction stream. The quorum system is the defense against individual malfunction or malfeasance. In later phases, validators are removed from the transaction stream, replaced by chain-tip oracles. 146 | 147 | In either case, front running is possible (inserting one’s own transaction before one provided to you by an external party). 148 | 149 | ### Canceling a Transfer 150 | 151 | To ensure a robust system, additional sets of Metronome smart contracts may support the canceling of a transfer. At this point there is no plan to develop this feature. 152 | 153 | An outline of how Metronome could support this would first involve canceling a pending Import event (before it has been fully validated and before tokens on the Destination chain have been minted). This cancellation would be observed by the validators, and they would propagate this event back to the Source chain where tokens would be re-minted. 154 | 155 | ### Validator Scalability 156 | 157 | Validators can scale as the number of chains grows. 158 | 159 | ![Figure 3](img/Figure-3.png) 160 | 161 | Given a set of n chains, there are n*(n-1)/2possible edges where we would want to support a transfer. 162 | 163 | ## System Components and Design 164 | 165 | Below we outline a design for a cross-chain transfer of Metronome tokens. We then supply various implementation details that show how the requirements are met for such a transfer. 166 | 167 | ### Token Transfer Overview 168 | 169 | The diagram below illustrates the steps taken that result in a transfer of Metronome tokens from a Source chain to a Destination chian. 170 | 171 | ![Figure 4](img/Figure-4.png) 172 | 173 | The user, utilizing a Wallet, initiates the transfer by exporting tokens from the Source chain, which results in those tokens being burned. 174 | 175 | An Export receipt is then provided to the Destination chain, which contains various parameters of the export as well as a Merkle root hash calculated from Source chain burn transactions (regardless of Destination chain). At this point an Import event is emitted from the Destination chain. 176 | 177 | Validators observe these Import events from the Destination Chain and verify the transaction against the Source chain. This involves verifying that the Export receipt exists in the specified block of the Source chain, validating existence of that event in the block’s Merkle tree. 178 | 179 | Next the validators contest to the validity of an Import event by voting on the Destination chain. The validator supplies a Merkle path when voting, allowing for the Destination chain smart contract to verify that the path is in the root. This only requires that the Destination chain store the Merkle root, and not the entire tree or path. 180 | 181 | Validators receive a small fee in compensation for performing their validation service. This introduces some additional collusion risk in phase 1. 182 | 183 | Once the Destination chain smart contract has received sufficient positive votes for an Import, the appropriate number of tokens are minted and the Import is deemed complete. 184 | 185 | The MET owner exporting to a new chain has to pay a small export fee. The export fee will be paid in MET and this will be calculated either percent of export amount or minimum flat export fee whichever is higher. After validations, this fee will be equally distributed among all validators at destination chain. Fee percentage and minimum fee will be defined in Metronome contracts. 186 | 187 | ### Event Emission 188 | 189 | The validators must not act on an emitted Import event until it has a block height of at least 4000-5000 (meaning that 4000-5000 blocks have been mined beyond the block containing the transaction with the given event) - about 24 hours. This is to avoid forking and mitigate the effects of 51% attacks. 190 | 191 | ### Maintaining Global MET Supply 192 | 193 | Maintaining the global supply of MET tokens requires that each chain have enough internal knowledge to independently determine what portion of the global supply is currently on its chain. At the time of each daily minting (midnight UTC for every MET deployment), the smart contract is able to calculate the expected global supply by using the genesis time of the very first Metronome smart contracts that were deployed onto the Ethereum network (this value will be hardcoded into the smart contract as a constant). The smart contract also knows what supply of MET are on its chain, and thus is able to calculate the portion of global MET on this chain. 194 | 195 | Since a MET token transfer between chains is not an atomic operation, there can be timing issues of the Export and Import events that affect the daily minting calculations. The simplest case is when both the Export and Import events are completed on the same day. The Source chain would have atomically burned the tokens and the Destination chain would have minted the same number of tokens. The global supply remains constant, and each chain knows its appropriate share. 196 | 197 | An issue does arise if the Export event occurs shortly before midnight UTC (the daily minting time), but the Import event does not complete until some time after midnight. The Source chain will have burned the tokens and at midnight minted a proportionally smaller number of tokens. Since the Import event has not yet completed on the Destination chain, the daily minting calculation on that chain will not include these tokens. This is an improbable edge case, but needs mentioning. 198 | 199 | This situation is detectable by the Destination chain smart contract since contained in the burn receipt is the burn time of the tokens. The contract can calculate whether that time occurred on a previous day. It still remains to be determined if we would mint some appropriate number of tokens at that point, or save this calculation for the next daily minting. 200 | 201 | It should be noted that chains should not simply include pending Import events when calculating their total supply, as this would allow users to submit invalid Import events and artificially raise the expected token supply on that chain. 202 | 203 | If we do not correct for this potential undersupply of Metronome tokens, the issue will compound over time and the difference between the theoretical global supply and the actual global supply will increase. 204 | 205 | We can call the state of MET tokens that are exported from the source lily pad, but not yet imported into the destination lily pad, **limbo**. We can see that a certain amount of tokens will be in limbo at any given time, and a subset of these will never be imported into the destination chain (lost/destroy/vaulted forever). 206 | 207 | ### Smart Contract Voting 208 | 209 | During Phase 1, each deployed set of Metronome smart contracts has methods whereby the Owner of the contracts can add or remove validators (essentially maintaining a whitelist) and set the number of successful votes that is required for an Import event to be accepted. 210 | 211 | A vote can either be positive or negative. If the validator believes an Export event is valid it casts a positive vote, otherwise it casts a negative vote. 212 | 213 | For either kind of vote to be accepted, the hash of the burn transaction must be signed by the validator. Each validator’s public key [hash] will be stored on chain such that the smart contract can verify a signed vote. 214 | 215 | The acceptance of a positive vote from a validator also requires a successful Merkle proof. The Wallet provides the Destination chain smart contract with a Merkle root. This root is calculated from burn transactions on the Source chain. The general flow is diagrammed below. 216 | 217 | ![Figure 5](img/Figure-5.png) 218 | 219 | Either the Source chain smart contract or the Wallet is responsible for calculating the Merkle root . The diagram above shows the smart contract calculating the root. The trade off here is the high gas cost of having the smart contract calculate the root versus the Wallet having to read enough burn transaction from the Source chain to calculate the root, essentially complicating the Wallet. 220 | 221 | The number of leaves to include in the Merkle tree is limited to 16 in order to prevent the tree from growing unbounded. This will limit the Merkle path length to a value of log2(16)=4. In the case where there are fewer than 16 burn transactions, all of them should be used in calculating the Merkle root. 222 | 223 | The validator calculates the Merkle path, having access to Export events from the Source chain, and provides this path to the Destination chain smart contract upon voting. 224 | 225 | To accept a positive vote, the Destination chain smart contract must verify that: 226 | - The validator address is whitelisted 227 | - The recovered address from the signature matches the validator’s public address 228 | - The validator has not yet voted for this Import event 229 | - The merkle path provided by the validator leads to the Merkle root previously set by the Wallet 230 | 231 | The same steps are followed to accept a negative vote except the last one, verifying a Merkle proof. 232 | 233 | If a vote passes, which is saying the minimum number of validators have cast a positive vote, the Destination chain smart contract will: 234 | - Pay the validator fees (described in more detail below) 235 | - Mint MET tokens 236 | - Set a flag (or some equivalent construct) to prevent further voting on this Import event 237 | 238 | If a vote fails, which is saying the minimum number of validators have cast a negative vote, the Destination chain smart contract will: 239 | - Pay the validator fees (described in more detail below) 240 | - Set a flag (or some equivalent construct) to prevent further voting on this Import event 241 | 242 | ### Adding or Removing Validators 243 | 244 | The Metronome smart contracts must be supplied with a list of known validators from which to accept votes. At launch of the validator network, there will be around n validators. The owner of the Metronome smart contracts will have the right to add or remove individual validator addresses. The contract owner only exists for phase 1, phase 2 and beyond no longer require contract owners. The contract owner from Phase 1 will be reassigned to the contract itself. 245 | 246 | The contracts must also be supplied with the minimum number of positive votes that are acceptable for an Import event to succeed. Only the Phase 1 owner of the contracts will be able to change this value. 247 | 248 | Eventually, as we move towards a more open and decentralized strategy for validators, it may not be feasible to update every blockchain with every known validator. Chains will independently determine if a validator has sufficient reputation to cast votes. 249 | 250 | **Phase 1** - Federated Network of Validators 251 | 252 | The owner address of the Metronome contracts on a chain will be able to add or remove validators in the Metronome ecosystem. This is only done if a quorum of validators approves the additional or removal or key rotation. 253 | 254 | **Phase 2** - Chain Attestors 255 | 256 | Chain-specific oracles manage themselves in a community-defined manner. ETC oracles may be managed differently from EOS oracles, managed differently from ETH oracles. 257 | 258 | **Phase 3** - No Attestors or Validators 259 | 260 | Phase 3 will use a stake weighted system for chain addition, removal, and fork election. There are no attestors or validators to add or remove. 261 | 262 | 263 | ### Adding and Removing Chains 264 | 265 | Adding a chain equates to deploying the Metronome smart contracts onto another blockchain, and informing the other blockchains and validators of its existence. 266 | 267 | Each chain is assigned some integer identifier, as determined by the owner of the Metronome smart contracts. This value, call it the chain-identifier, must be provided to every previously deployed Metronome smart contract as well as to any validators that will be communicating with this new chain. 268 | 269 | **Phase 1** - Federated Network of Validators 270 | 271 | In phase 1, the trusted validator network will consider the technical, security, and community characteristics of new chains and contracts. The contract owner will then add new chains in the contracts based on a quorum of validator approval. 272 | 273 | **Phase 2** - Chain Attestors 274 | 275 | In Phase 2, anyone can add a new contract set to the Metronome ecosystem, but will need to identify the chain attestor associated with that new set of contracts. For example, if someone added a set of Metronome contracts to chain A, they likely would have chain A’s foundation as the chain attestor – as it can be assumed that chain A’s foundation would act in the best interests of chain A. 276 | 277 | Once added, the wider Metronome community would decide if this addition is valid or invalid based on a stake-weighted mechanism. 278 | 279 | **Phase 3** - Stake Weighted Blockchain of Blockchains 280 | 281 | Phase 3 will not have chain attestors, even at contract deployment. Instead, anyone can launch a new set of contracts and the community would then determine if the contracts added are valid or invalid via the aforementioned stake-weighted consensus mechanism. 282 | 283 | The newly deployed Metronome smart contracts must be supplied with: 284 | - The chain-identifier assigned to this chain. 285 | - Identifiers of all other existing chains with a Metronome deployment, along with the addresses of these other contracts. 286 | - A timestamp value from the genesis Metronome smart contract, in order to calculate the expected daily total supply (see section on maintaining global MET supply). 287 | 288 | These identifiers are distributed as a simple precaution and to provide sanity checking. For instance, a request to generate an Export event will ensure that the Destination chain identifier supplied is known. Conversely, an Import will only be accepted if the Destination chain identifier is the same as that chain’s identifier. This additional level of checking comes at the cost of maintaining and distributing this information to all chains where Metronome is deployed. 289 | 290 | In order to support removal of a chain, the reverse of the above actions would be taken. 291 | 292 | ### Fees 293 | 294 | In order to reward and incentivize validators, and also to establish a system that will allow for more decentralized validators in the future, the Metronome smart contracts support payment of fees to process transfers. Validators will set their own fees. This fee is later distributed to the validators after a vote is accepted or rejected. If an event is accepted, the fee is only paid to those validators that cast a positive vote. Conversely, if an event is rejected, only validators that cast a negative vote will receive the fee. Phase 2 will have attestors set their fees, and phase 3 will not have attestors or validators, meaning the only fees will be those associated with the underlying network. 295 | 296 | The Wallet, and thus the end user, pays the gas cost during the import or claim call on the Destination chain plus some minimum fee in the native currency of that chain. The user has the option of paying more than the minimum to encourage validators to race to process the transfer. 297 | 298 | The fee is collected in MET, as 0.5% of the MET to be transferred. The collected fees are evenly distributed amongst the validators. 299 | 300 | This fee structure is specific to phase 1, and will be phased out in future phases. 301 | 302 | ## Conclusion 303 | 304 | Several designs were considered in the process of formalizing the current solution to support Metronome token transfer between different blockchains. The current design provides a good balance between the trade-offs involved. All Wallet interactions happen early in the transfer and we get the benefits of auto-minting of the tokens on the Destination chain. 305 | 306 | ### Further Analysis Needed 307 | 308 | More analysis should be done on the fee payment proposed here, with an eye towards modeling the expected behavior of validators. This may not be necessary at first, since validators will be trusted entities, but will become necessary when validators become more decentralized. 309 | 310 | We should specify an approach for the validators to sign the Export event and for the Destination chain smart contract to verify their signature. 311 | 312 | More thought needs to be put into the design for validators to add themselves in a more decentralized way. We imagine a system on chain that maintains reputation of some sort. Validators would self-register and begin voting, although their votes would not be counted until they have built up a reputation. Reputation could be gained by casting successful votes in a timely manner. When voting, Validators could stake tokens or some native currency. Considering the novelty of the voting design outlined here, the smart contracts that handle voting should be designed such that they are later upgradeable. 313 | 314 | There may still be some unsolved issues with handling contentious hard forks. For instance, the global supply limit may be broken if a user successfully transfers MET from a fork before the Metronome community has had a chance to remove that fork from the list of valid chains. 315 | 316 | Some thought should be put into a way to support canceling an Export. This could happen by canceling the pending Import on the Destination chain, and effectively following the same validator flow in the other direction. Validators verify a canceled pending Import event, and vote on reverting the original Export event on the Source chain. 317 | --------------------------------------------------------------------------------