Firstly, I want to thank you for joining us here to discuss inscription technology within the Ethereum ecosystem, and I deeply respect and congratulate you on your current achievements.
As you pointed out, there are indeed some differences between our ERC7583 protocol and the direction you advocate. These differences are mainly reflected in our chosen technical specifications and the way inscription data is stored. We believe that in this industry, which respects individual differences and encourages innovation, different solutions can not only coexist but also collectively promote the development of the entire field.
Specifically, ERC7583 prefers to use Event data to store inscription data, aiming to enhance its compatibility and interoperability. This approach allows developers to leverage the powerful capabilities of the EVM for more flexible secondary development of inscriptions. Compared to off-chain indexers, asset ownership determined by smart contracts offers stronger persuasiveness. Additionally, ERC7583 is designed to provide new solutions for interactions between on-chain and off-chain computations. For example, like your music platform, transactions can be conducted through smart contracts while using indexers to parse and play content. Whether it’s gaming, the metaverse, or any other application, customized indexers can be used to integrate on-chain and off-chain elements (This is similar to the concept of the ’ Ethscriptions VM’ that you proposed).
Although ERC7583 and Ethscriptions have their independent development paths, I still hope to invite you with the utmost respect to join us in pushing ERC7583 forward, until it reaches its Final status.
Thank you very much for your response. I completely agree that it is our shared responsibility to learn from and respect history. I sincerely respect and acknowledge the significant achievements of Ethscriptions, and I pay homage to their pioneering status in this field.
At the same time, I eagerly hope that we can work together to jointly promote the development of the ETH inscription ecosystem. We believe that through our combined efforts, this ecosystem will thrive and prosper!
Events and calldata both can only be accessed offchain.
Events are easier to access given today’s indexers, but these were not designed for Ethscriptions! We should “skate to where the puck is going.”
The only functional difference is whether users have to pay once—Ethscription content in calldata—or twice: Ethscription content in calldata and also in an event.
Also this requires someone pay the cost of deploying a contract, which is another dependency.
I believe events have their place and we’ve made use of them, but I don’t see the reason to disallow the original and cheapest method which is calldata-only.
100% of your goals can be achieved without making users pay more. Why force them to do this without a benefit?
In the INSC smart contract, the only role with special access is the proxy, and it has only one function, which is to switch the contract to FT mode. We cannot guarantee that there will be no new vulnerabilities after switching to FT, which is why we haven’t made this decision. If we do switch, it also means that we are acknowledging the state after the hacker attack, which is unacceptable.
Ultimately, we decided to take a snapshot and analyze all the transaction data. Through the ‘refund strategy’, we aim to facilitate the rollback of all transactions. We have also developed a transaction data analyzer as quickly as possible and submitted it to this Github repository.
Currently, there is only one way to ensure compensation for everyone’s assets, and that is to support INS.EVM. By collectively promoting its development, we can help it grow strong once again.
You have now received compensation, but what about others? We are currently making our utmost efforts to promote the development of INS.EVM. What you need to do now is to patiently wait; all the work is proceeding in an orderly manner.
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
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.
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!
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.
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.
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.
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!
