Anchor, a key-value system base on substrate

[ff13dfly]

Project Abstract

Anchor is a key-value on-chain storage system based on substrate, which is convenient for developing on-chain applications (cApp). By this way, you can develop blockchain app totally on Javascript. Compared with Pallet and smart contracts, the technical threshold is much lower, and the efficiency is much improved, allowing developers to pay more attention to the application itself.

Anchor can also be regarded as a domain name service, similar to ENS (Name service of Ethereum) , which can capitalize the simple and easy-to-remember key (chain name), and gradually become valuable in the case of free transactions. This value is not just static data, but also applications. This trusted on-chain data can also be accessed into the future metaverse.

For which grant level are you applying?

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $50,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for > $100k Web3 Foundation Council approval)

Application Checklist

• The application template has been copied, renamed ( project_name.md) and updated.
• I have read and understood the FAQs, application guidelines and announcement guidelines.
• A BTC or Ethereum (DAI/USDT) address for the payment of the milestones is provided inside the application.
• I have read and acknowledge the terms and conditions.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted.
• I prefer the discussion of this application to be in a private Element/Matrix channel. My username is: @_______

How Did You Hear About our grants program?

• Social Media
• Hackathon
• Personal Recommendation
• Substrate Builders Program
• Investor/VC
• Online Search
• Other: _______

[semuelle]

Thank you for your application, @ff13dfly. I see you already put quite some work into this project. Before I share this with the rest of the team, could you

• raise the code coverage percentage for the test deliverables (should be closer to 80 or 90%),
• explain what you mean by "app development decoupled from assets",
• explain what you mean by "service that can quickly calibrate the content on the chain"?

Also, there have been numerous attempts at creating name service pallets and tuple storage pallets (see, e.g. "Name Service" in our tech stack doc). It would be great if you could describe in your application how your approach is better or different. Also, this PSP might be relevant.

Lastly, just to verify, the "blog capp" deliverable would have to be open source and come with a brief explanation how to set it up yourself and how to use it.

[ff13dfly]

Thank you for your application, @ff13dfly. I see you already put quite some work into this project. Before I share this with the rest of the team, could you

• raise the code coverage percentage for the test deliverables (should be closer to 80 or 90%),
• explain what you mean by "app development decoupled from assets",
• explain what you mean by "service that can quickly calibrate the content on the chain"?

Also, there have been numerous attempts at creating name service pallets and tuple storage pallets (see, e.g. "Name Service" in our tech stack doc). It would be great if you could describe in your application how your approach is better or different. Also, this PSP might be relevant.

Lastly, just to verify, the "blog capp" deliverable would have to be open source and come with a brief explanation how to set it up yourself and how to use it.

Hi @semuelle , Thanks for the review. I wrote in Chinese then translated to English, that causes some misunderstanding.

Q1 : raise the code coverage percentage for the test deliverables (should be closer to 80 or 90%)
Ok, will modify the milestones.

Q2 : explain what you mean by "app development decoupled from assets"
This is a very important aspect about Anchor in my opinion. Currently, when you want to test an App base on blockchain, you need to own some coins or token. App pays more attention to coin and token.
This is not good for some kind of App, like the cApp 'blog', normal users are free to view, editor or writer need fee to write. And the cost of writing to the chain is just fee that can be understood easily.

Q3 : explain what you mean by "service that can quickly calibrate the content on the chain"?
Sorry for the translation. I wrote in Chinese then translated to English.
Suppied one : Simple NS service that can quickly calibrate the content on the chain.
Modified one : Simple Name Service that can quickly locate the content on the chain.
You can use a normal name to locate the content on chain.

Q4 : What's the difference of Anchor to other "Name Service" ?
It is very important question to answer. At the beginning, my aim is to load a virtual world ( now it is called metaverse ) on blockchain, then I found Substrate/Polkadot. After a period time of studying and I find the way to load App on chain. Evently, it looks like a " Name Service ".
Actually, the " Name Service " is quite charming , it gives the owner of Anchor a hope that the Anchor name can be like domain name and will become valueable in the future. From the metaverse view, it is valueabe too, you can create great 3D object or something else base on Anchor, then you can sell it. Maybe, it may create an economic cycle.
Anchor key-value system is not just for development, but also try to create an economic cycle.

Q5 : Lastly, just to verify, the "blog capp" deliverable would have to be open source and come with a brief explanation how to set it up yourself and how to use it.
Yes, it is. The code is here https://github.com/ff13dfly/cApp. Currently, the code comments is in Chinese, will improve that soon. I have tried "twitter cApp", but it is much complex than blog. I will finish that after this apply.

[semuelle]

Thanks for the quick reply, @ff13dfly. Two follow-up questions:

• Question 4 was about other name service implementations. Can you have a look at existing solutions and explain in your application what you are doing differently and why another implementation is needed?
• I had a quick look at the blog cApp repository, and couldn't find any reference to on-chain data. It looks like they come from agent here?

[ff13dfly]

Thanks for the quick reply, @ff13dfly. Two follow-up questions:

• Question 4 was about other name service implementations. Can you have a look at existing solutions and explain in your application what you are doing differently and why another implementation is needed?
• I had a quick look at the blog cApp repository, and couldn't find any reference to on-chain data. It looks like they come from agent here?

Q4 : Question 4 was about other name service implementations. Can you have a look at existing solutions and explain in your application what you are doing differently and why another implementation is needed?
Have checked Substrate Names, it seams to be the solution I want. Will try to run and check in details.

Q6 : I had a quick look at the blog cApp repository, and couldn't find any reference to on-chain data. It looks like they come from agent here?
The browser "vExplorer" will load the cApp and supply the linker to Anchor network via Polkadot.js.
I record a video to show the flow how cApp works.
https://www.youtube.com/watch?v=_PloJjBcito

Because of the key question 4 , I will try and check wether "Substrate Names" fit the remand of cApp development.
No need to reinvent the wheel. Can you give me a week to do and can this apply been pending during this period ?

[semuelle]

Do you mean this Substrate Names? Note that it is quite outdated and would probably require a rewrite. It wouldn't be an issue if you reused existing work in your grant, though.

Can you give me a week to do and can this apply been pending during this period ?

Of course. Take your time. I'll put this PR on hold until then.

[ff13dfly]

Do you mean this Substrate Names? Note that it is quite outdated and would probably require a rewrite. It wouldn't be an issue if you reused existing work in your grant, though.

Yes, tried to run tomorrow, and found it bases on substrate 2.0. But the demand of Anchor is the same as Substrate Names , or say, improve the demand of loading application .
Will test the other NS Grant to compare at the holding period.
Thanks, :-)

[ff13dfly]

Hi, @semuelle , it took time to try to run the name service implementations. Comparing them on the follow table, although did not test all of them , because I am not good at Rust, can not figure out all the errors.

In short, Anchor looks the same as Substrate Names which is base on substrate 2.0.0, but improve the data struct to support cApp development.
Is is possible that I discuss the cooperation with the original author of Substrate Names and continue the development to apply Grant ?

[ff13dfly]

Hi, @semuelle , it is good to tell you that I have developed the functions. It did not cost so much time , and I can focus on cApp development now.
From Substrate view, this application is not so charming.
Will continue to develop on Substrate/Polkadot, hope to find a good idea when moving forward. :-)

Please close this apply, thanks.

[semuelle]

Hey @ff13dfly. Sorry for the late reply, I was out of office for a few days.

Thank you for taking the time to share your research and findings, and for being honest about your verdict. I'd be interested in how you came to these conclusions, such as the low ENS on Substrate stability. Would you mind sharing your methods?

Also, can you explain what you mean by "From Substrate view, this application is not so charming."?

Regarding your first comment: if a project is abandoned although it proved useful, we are always happy to see others take over, whether it's a transfer of ownership of a simple fork of the repository. We offer maintenance grants for these kinds of situations.

Please keep us up to date about your endeavours and feel free to apply again!