Add ERC: Inscription In Smart Contract

ERCS/erc-7583.md

@@ -0,0 +1,119 @@
+---
+eip: 7583
+title: Inscription In Smart Contract
+description: A framework for integrating inscription data within smart contract events.
+author: Shalom Mizrahi (@shalom-ins), Shalom Mizrahi <insevm@insevm.trade>
+discussions-to: https://ethereum-magicians.org/t/discussion-on-erc7549-for-inscribing-data-in-smart-contract/17661
+status: Draft
+type: Standards Track
+category: ERC
+created: 2023-12-26
+---
+
+## Abstract
+
+This EIP proposes a standardized method for embedding inscription data within events emitted by Ethereum smart contracts. It aims to establish a uniform format for encoding and decoding inscription data, ensuring interoperability and consistency across different contracts and platforms.
+
+## Motivation
+
+Since March 2023, inscriptions have gradually gained recognition in the market as a new form of asset issuance. The core idea of inscriptions is to embed specific data or information into the blockchain in an immutable form, granting the data characteristics of tamper-proofing and permanent storage. While on the Bitcoin network, inscriptions cannot be directly computed and processed on-chain, the community widely acknowledges the pattern of on-chain storage and off-chain interpretation. This approach ensures the security and authenticity of the data while showcasing the potential of blockchain technology in data ownership.
+
+However, there are many limitations in the existing implementations of inscriptions. The Ethereum Virtual Machine (EVM) serves as a powerful smart contract execution environment capable of handling more complex logic and interactions. Currently, the application of inscriptions is primarily limited to simple data recording, without fully leveraging the computational capabilities of the EVM. This has resulted in the untapped potential of inscriptions, particularly in application scenarios that require on-chain logic processing and interaction with smart contracts.
+
+Therefore, it is crucial to develop an EIP that standardizes the handling of inscription data. Such a standard would not only facilitate the effective utilization of inscription data but also unlock new application scenarios such as on-chain copyright management, data ownership verification, digital identity authentication, and more. By standardizing the format and processing of inscription data, we can make inscription data an integral part of the EVM's computation capabilities, thereby expanding the scope of inscription usage in decentralized finance (DeFi), non-fungible tokens (NFTs), and other blockchain applications.
+
+## Specification
+
+This EIP introduces a new smart contract event, Inscribe, for inscribing data on the Ethereum blockchain.
+
+### Event Definition
+
+```solidity
+/// @title ERC-7583 Inscription Standard in Smart Contracts
+interface IERC7583 {
+  event Inscribe(bytes data);
+}
+```
+
+- The `Inscribe` event MUST be defined in a standard Ethereum smart contract that implements this protocol.
+- The `data` field is a byte array used to store the inscription data.
+
+### Data Encoding
+
+The data in the `data` field MUST be encoded following the data URI scheme defined in RFC 2397.
+
+### Data Interpretation
+
+Clients or services implementing this standard MUST be capable of parsing data URIs compliant with RFC 2397 to extract and utilize the inscription data, ensuring consistency and accessibility of inscription data.
+
+## Rationale
+
+The decision to design the Inscribe event as event Inscribe(bytes data); was motivated by the intention to make the inscription process as flexible and resource-efficient as possible. By choosing a single bytes data type for the inscription data, the design allows for encapsulating a wide variety of semantically rich data, which can be interpreted and indexed by off-chain services or indexers. This approach is advantageous for several reasons:
+
+### Flexibility and Universality
+
+A bytes array is versatile and can store any form of data, whether it's plain text, encoded JSON, or even binary data. This flexibility is crucial for a standard that aims to serve a wide range of applications and use cases in the Ethereum ecosystem.
+
+By not restricting the format of the data within the bytes array, the standard allows for future extensions and adaptations without needing modifications to the contract interface.
+
+### Resource Efficiency
+
+Adding multiple fields to the event could lead to unnecessary resource consumption, especially considering gas costs on the Ethereum network. A single bytes field minimizes the overhead and makes the inscription process more gas-efficient.
+
+Keeping the event structure simple also aids in reducing the complexity of smart contract development and interaction, making it more accessible to a broader range of developers.
+
+## Backwards Compatibility
+
+This EIP introduces a new standard for inscribing data on the Ethereum blockchain, which primarily concerns the addition of the Inscribe event. While the proposal is designed to be inherently backward compatible, as it does not modify any existing structures or behaviors of the Ethereum network, there are potential considerations regarding the volume of inscribed data.
+
+### Potential Impact on Block Size and Network Congestion
+
+The introduction of the Inscribe event, allowing arbitrary bytes of data to be embedded, might lead to scenarios where large volumes of data are inscribed onto the blockchain. This could potentially increase the size of individual blocks.
+
+Larger blocks can have several implications, such as increased block propagation times and heightened network congestion. This is especially pertinent during periods of high network activity, where the introduction of significant additional data could exacerbate the existing load.
+
+While the flexibility of the Inscribe event is a key advantage, it also places responsibility on developers and users to use this capability judiciously. Overuse or abuse of this feature, particularly with large data payloads, could have unintended consequences on network performance and costs.
+
+### Mitigation Strategies
+
+Ethereum currently imposes inherent limitations on event logs' size, as discussed on platforms like Ethereum Stack Exchange. These limits are crucial in preventing the blockchain from becoming bloated with excessively large data payloads.
+
+Developers and users are encouraged to be mindful of these limitations when utilizing the Inscribe event. Implementations should aim to optimize data efficiency, ensuring that inscribed data is concise and necessary, thereby aligning with the network's current event handling capacity.
+
+## Reference Implementation
+
+This is a minimal implementation:
+
+```solidity
+Interface IERC7583 {
+  event Inscribe(bytes data);
+}
+
+contract INS20 is IERC7583 {
+  event Inscribe(bytes data);
+
+  constructor(){}
+
+  function inscribe(bytes calldata data) public {
+    emit Inscribe(data);
+  }
+}
+```
+
+## Security Considerations
+
+### Data Integrity and Validity
+
+The Inscribe event allows for the embedding of arbitrary data, which raises concerns about the integrity and validity of the data being inscribed. It is essential to consider mechanisms to verify the authenticity and accuracy of the data, especially when used in applications that rely heavily on the integrity of inscription data.
+
+Implementations should consider using cryptographic techniques like digital signatures or hash functions to validate the data before inscribing it on the blockchain.
+
+### Privacy Concerns
+
+Depending on the nature of the inscribed data, there may be privacy implications, especially if personally identifiable information (PII) or sensitive data is being stored on-chain.
+
+Implementations should provide clear guidelines on the types of data suitable for inscription and consider incorporating privacy-preserving techniques where necessary.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).