EIP-2309: ERC-721 Consecutive Transfer Extension (ethereum#2310)

* EIP-2309: ERC-721 Batch Mint Extension

* update name to consecutive transfer

* update status to last call

* Update status to draft

EIPS/eip-2309.md

@@ -0,0 +1,108 @@
+---
+eip: 2309
+title: ERC-721 Consecutive Transfer Extension
+author: Sean Papanikolas (@pizza_r0b)
+discussions-to: https://github.com/ethereum/EIPs/issues/2309
+status: Draft
+type: Standards Track
+category: ERC
+created: 2019-10-08
+requires: 721
+---
+
+<!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
+
+## Simple Summary
+
+<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
+
+A standardized event emitted when creating/transferring one, or many non-fungible tokens using consecutive token identifiers.
+
+## Abstract
+
+<!--A short (~200 word) description of the technical issue being addressed.-->
+
+The optional ERC-721 Consecutive Transfer Extension provides a standardized event which could be emitted during the creation/transfer of one, or many non-fungible tokens. This standard does not set the expectation of how you might create/transfer many tokens it is only concerned with the event emitted after the creation, or transfer of ownership of these tokens. This extension assumes that token identifiers are in consecutive order.
+
+## Motivation
+
+<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
+
+This extension is provides even more scalibility of the ERC-721 specification. It is possible to create, transfer, and burn 2^255 non-fungible tokens in one transaction. However, it is not possible to emit that many `Transfer` events in one transaction. The `Transfer` event is part of the original specification which states:
+
+> This emits when ownership of any NFT changes by any mechanism.
+> This event emits when NFTs are created (`from` == 0) and destroyed
+> (`to` == 0). Exception: during contract creation, any number of NFTs
+> may be created and assigned without emitting Transfer. At the time of
+> any transfer, the approved address for that NFT (if any) is reset to none.
+
+This allows for the original `Transfer` event to be emitted for one token at a time, which in turn gives us O(n) time complexity. Minting one billion NFTs can be done in one transaction using efficient data structures, but in order to emit the `Transfer` event - according to the original spec - one would need a loop with one billion iterations which is bound to run out of gas, or exceed transaction timeout limits. This cannot be accomplished with the current spec. This extension solves that problem.
+
+Many decentralized marketplaces and block explorers utilize the `Transfer` event as a way to determine which NFTs an address owns. The Consecutive Transfer Extension provides a standard mechanism for these platforms to use to determine ownership of many tokens.
+
+## Specification
+
+<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+"OPTIONAL" in this document are to be interpreted as described in
+RFC 2119.
+
+**ERC-721 compliant contracts MAY implement this Consecutive Transfer Extension to provide a standard event to be emitted at the time of creation, burn, or transfer of one or many consecutive tokens**
+
+```solidity
+pragma solidity ^0.5.10;
+
+/**
+  @title ERC-2309: ERC-721 Consecutive Transfer Extension
+  @dev https://github.com/ethereum/EIPs/issues/2309
+ */
+
+interface ERC721ConsecutiveTransfer /* is ERC721 */ {
+  /**
+    @notice This event is emitted when ownership of a consecutive batch of tokens changes by any mechanism.
+    This includes minting, transferring, and burning.
+
+    @dev The address executing the transaction MUST own all the tokens within the range of
+    fromTokenId and toTokenId, or MUST be an approved operator to act on the owners behalf.
+    The fromTokenId and toTokenId MUST be a consecutive range of tokens IDs.
+    When minting/creating tokens, the `fromAddress` argument MUST be set to `0x0` (i.e. zero address).
+    When burning/destroying tokens, the `toAddress` argument MUST be set to `0x0` (i.e. zero address).
+
+    @param fromTokenId The token ID that begins the batch of tokens being transferred
+    @param toTokenId The token ID that ends the batch of tokens being transferred
+    @param fromAddress The address transferring ownership of the specified range of tokens
+    @param toAddress The address receiving ownership of the specified range of tokens.
+  */
+  event ConsecutiveTransfer(uint indexed fromTokenId, uint toTokenId, address indexed fromAddress, address indexed toAddress);
+}
+```
+
+The `ConsecutiveTransfer` event can be used for a single token as well as many tokens:
+
+**Single token creation**
+
+`emit ConsecutiveTransfer(1, 1, address(0), toAddress);`
+
+**Batch token creation**
+
+`emit ConsecutiveTransfer(1, 100000, address(0), toAddress);`
+
+## Rationale
+
+<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
+
+Standardizing the `ConsecutiveTransfer` event gives decentralized platforms a standard way of determining ownership of large quantities of non-fungible tokens without the need to support a new token standard. There are many ways in which the batch creation and transfer of NFTs can be implemented. The Consecutive Transfer Extension allows contract creators to implement batch creation, transfer, and burn methods however they see fit, but provides a standardized event in which all implementations can use. By specifying a range of consecutive token identifiers we can easily cover the transfer, or creation of 2^(256-1) tokens and decentralized platforms can react accordingly.
+
+Take this example. I sell lemons and have a farm with 10,000 lemon trees and 1,000 new lemon trees every few years. I want to turn each lemon tree into a non-fungible token that people can own. Each person that owns one of my non-fungible lemon tree tokens will receive a quarterly percentage of each harvest from that tree. The problem is that I would need to create and transfer each of these tokens individually - which will cost me a lot of time and money and frankly would keep me from doing this.
+
+With this extension I would be able to to mint my initial 10,000 lemon tree tokens in one transaction. I would be able to quickly and cheaply mint my additional 1,000 lemon tree tokens when a new batch is planted. I would then be able to transfer all of the 10,000+ lemon tree tokens to a special smart contract that keeps track of the selling and distribution of funds in one transaction all while adhering to a specified standard.
+
+<!-- ## Implementation
+
+<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).