Sir, please ignore the noise and continue your great job, we as the loyal supporters are witnessing a great project emerging and will always stand by your side
we the holders will always support INS-EVM anyway.
Time will tell, just patiently wait, I can see whether the project is developing or not. Don’t fud please
支持创作者，时间会证明一切 
1 Like
Going back and organizing the data is a huge task, it’s not easy. Hopefully the project will be moved forward soon, all we can do is be patient and support you, Captain!
Time will tell.
Make INS-EVM great!
1 Like
You are underestimating the power of the Ethereum developer community. Have you considered not passing data through calldata, but instead generating it directly within the contract and writing it in an event? This is entirely feasible, and in fact, already exists, for example in OKPC. In this case, the consumption of calldata can be negligible, with only the gas consumption for event data.
@TUTUBIG @ins-evm Great discussion and ideas.
Indeed, the recording of inscribed transactions is missing. However, I believe that inscription event should be treated as a separate event, distinct from the transfer event.
I am not convinced about this. Do you view inscriptions as entities/artefacts which should be traded independently of tokens? What are the use cases which could not be covered by the current Transfer event?
- The unique id has already been memtioned here.
- And it is a good practical solution for setting a max size of inscribed data! What do you think is the best practice for setting a max limit data size?
- I think the off chain could also be stored in ‘Inscribe’ event.
- Excellent!
- I think it may be okay to leave it up to each contract, but good to include in a description of best practices. The length would depend on the purpose of the contract and what’s it’s aiming to inscribe
- Agreed. Keep it simple.
Currently, inscriptions are operating within smart contracts on the EVM. For important data like the owner, how about using the storage variables of the smart contract to store it? e.g.
I may have been unclear. I did not mean the owner, but rather a reference to a user making the inscription.
–
@ins-evm Not specific to your proposal, but rather best practices for implementation: I noted in your contract that you only allowed inscription of a specific hash, and curious if you have other ideas about dynamic hashes or similar to add layers of security?
Excellent. Is there a possibility that in the development direction of ENS, it integrates with Ethscriptions, innovates on this basis, and collectively expands Ethscriptions? At the same time, everyone can complement each other, jointly promoting the rise of Ethscriptions on ETH. This way, we can face Odrinals and Brc-20 on BTC, as well as Runes in April, making us more valuable. I would like to hear your thoughts on this, looking beyond the individual products themselves.
1 Like
別鬧了老哥 回家放牛去吧 你在對協議造成傷害
2 Likes
do you mean it is not possible?
1 Like
Thank you very much for your offer of collaboration, for which I express my sincere gratitude. Currently, our team is focused on achieving our set plans and goals. Once these tasks are completed, we will consider and respond to your proposal for cooperation in more detail. I look forward to discussing potential collaboration opportunities in the near future.
2 Likes
Hello ins-evm, first of all, your project is very good and has ambitious goals. We are very happy to build and develop together!
However, due to the emergence of contract loopholes, a large number of people’s assets have been reduced to zero, which is something we don’t want to see.
Because of this, I am here to make a suggestion to you. I hope you can map the user’s assets to the new contract as soon as possible so that community members can feel at ease. I know this is a very large amount of work, but so many days have passed. It is difficult for people to wait calmly any longer. They all hope that their assets will be protected so that they can continue to develop together with the project!
Thank you for the suggestions you provided. We are indeed working towards this goal. As you suggested, we should provide the new mapping assets as soon as possible. Currently, our plan is to make the new mapping assets the first implementation of ERC7583. We won’t wait for ERC7583 to reach its final state, but it should be at least in a relatively stable state to avoid compatibility issues in the future.
Okay, I think everyone who has checked the forum knows your purpose, thank you!
But can you tell us when the new map will be available?
Everyone can wait and build with peace of mind!
1 Like
I responded in the GitHub pull request with a technical issue with the proposal as-written. Posting here to also voice concerns about the overall structure of this EIP:
In general, I feel this doesn’t need to be an EIP, since it doesn’t need to be a standard that multiple contracts implement. If people wish to give meaning to arbitrary data that is just announced/timestamped on an EVM blockchain, it doesn’t need to be implemented by multiple smart contracts (since that mentality is aiming to skew away from smart contracts). Instead, just one contract needs to exist with a method anyone can call, to trigger an event with arbitrary data. And actually many of those already exist from the early days of Ethereum when people were experimenting with simple “greeter” contracts. What benefit is to be gained by a project organizer deploying a smart contract for their project that allows people to trigger “Inscribe” events, but doesn’t use any other smart contract benefits?
That “only” is discounting one other thing I think is important: Event indexers already exist. Web3 SDK libraries give easy access to filter and query Events (as they’re exposed by the JSON-RPC node APIs), but calldata isn’t as easily filterable. An additional benefit you get by “paying twice” is the ability for many other nodes to present your data in a more convenient package, and so will show up in some form in explorers, wallets, and portfolio tools without them needing to specifically modify to support it.
If this is to become an accepted EIP, a technical concern with the formatting chosen: If the data value of the event is forced to be a data URI, then why is it defined as a bytes value rather than a string value? I would suggest dropping the requirement that it be a data URI in format, and allow any data to be present. That allows for implementations to use whatever data encoding they prefer (e.g. protobuf or BSON). Using BSON or Solidity data encoding would encode the data more compactly (and therefore reduce the cost to inscribe). The data URI format needing to start with data: means every inscription has five extra bytes it needs to pay to store.
2 Likes
The Ethereum Name Service (ENS) specification allows putting arbitrary key/value pairs on domains/names you own. There are several standard keys that define avatar images and demographic information about the owner, but you can put whatever you want in a domain you own. If you wish to put some structured data there and create a project that derives meaning from that you definitely can. But other users cannot modify the key/value pairs on your domain. So it can be a way for individual users to signal something, but cannot be used to have a back-and-forth “conversation” or log with other users adding data to it.
Support innovation, the ETH ecosystem is in great need of more innovation and this time will promote the use of ETH in more scenarios
Thank you very much for your valuable comments and suggestions. We deeply agree with your opinion that merely relying on an “inscribe” event without the need for standardization through EIP is sufficient.At the same time, limiting data to a data URI format was a decision made in consideration of the richness of protocol content, but it indeed was not a thoroughly considered decision.
Over the past period, we have been deeply reflecting and exploring, trying to find out what the best asset form for inscriptions in the EVM should be. Based on these reflections, we have updated our results in the GitHub repository and developed a marketplace platform to validate the feasibility and practicality of the ERC7583 protocol.
We highly value your opinions and suggestions, which are crucial for the improvement and perfection of the ERC7583 protocol. Therefore, we are very eager to hear more specific suggestions and feedback from you. Would you be willing to provide more advice on how to improve our protocol and its implementation? We look forward to further communication and cooperation with you, and once again, thank you for your time and contribution.
True, but no “out of the box” event indexers give you enough data to do anything useful because Ethscription state can depend on Ethscriptions created arbitrarily far in the past. So if you want to index Ethscription state you’re going to need a special-purpose indexer.
Do any such indexers built on the event model exist? I am not aware of any, certainly no open source ones.
On the other hand, the calldata model has an open source indexer that works great right here!
Why not use this (or a fork of it) versus hoping someone builds a better one using events and forcing users to pay the extra cost in the mean time?
My point was that there is a robust querying mechanism for Events already part of the standard RPC calls that can be made to any node. If you want to query Events of type “Foo” from a specific contract, for a specific block range (“arbitrarily far in the past”), one API call gets that. The RPC infrastructure allows getting the calldata from a transaction, but I don’t believe it has any means to search/query based on calldata. So if you’re creating “inscriptions” that are stored as calldata, yes you’ll need a custom indexer to scape the entire transaction history to find them, and then present some sort of custom querying interface to know about them. If you’re creating “inscriptions” that save their data as Events, you don’t need to create a custom indexer, because all nodes already know how to find and present that data to you on-demand; you don’t need to pre-fetch it and index it, just query it when you want it from a node.
Even if you did build a complex protocol on top of Event data, and needed an index to scrape all the data first, creating an indexer for Event data would be dramatically faster and easier to write, since it would be able to skip all the transactions that were irrelevant without fetching them. Indexing calldata would need to iterate over every transaction, fetching that transaction’s data from a node, and then determining if it’s needed for the protocol.
The latest updates to the GitHub draft lay out a radically different structure, with ERC7583 defining a type of contract that is a (true) ERC20 and (renamed/tweaked) ERC721 contract at once. That hybrid blend of non-fungible and fungible token is something that non-inscription communities have been exploring lately and ERC7631 has come from that. ERC7631 seems to be pursuing the same goals as this updated ERC7583, in that users have their fungible tokens saved as discrete “bundles” of arbitrary value. The key difference is ERC7631 has the non-fungible “bundles” be true ERC721s. A significant downside of this updated ERC7583 is that the non-fungible part looks similar to ERC721s, but isn’t actually, and could confuse or break interfaces that assume they are.
ERC7583 having part of the contract’s state be accessible to other smart contracts (ERC20 interface) and the other part inaccessible (by attempting to save it as “an inscription”) seems like it’s significantly less useful. So, my opinion is that if a project wants the functionality of having a set of non-fungible tokens that “store” fungible token values for a user, we should help standardize ERC7631 as an interface to do that, to have the best compatibility with all other smart contracts in the space.