Add Melodot proposal

[DarkingLee]

Project Abstract

Melodot is an incentive-compatible data availability layer. Melodot introduces the role of farmers by combining PoSpace, alleviating the system's dependence on the minimum number of honest nodes assumption, and completing an incentive-compatible distributed generation and data storage scheme. Consensus validators now act more like light clients, improving future scalability.

Grant level

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

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
• 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 (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[DarkingLee]

Hey @Noc2 and @keeganquigley , I hope you're both doing well! I created the proposal and would love to get your suggestions!

[Noc2]

Thanks for the application, and sorry for the late reply here. I have some quick initial feedback:

• All the headlines of your milestones currently say: "Example — Basic functionality". Could you update this?
• The estimation of the FTE and total costs seem strange to me. For example, milestone 4 has an FTE of 2 and one month compared to milestone 2, which has only an FTE of 1 and the same total costs.
• Are you aware of avail: https://github.com/availproject?

[DarkingLee]

hey @Noc2 , Thank you for your reply.

• I have updated them.
• It indeed seemed strange, so I carefully reviewed the milestones and made the following adjustments:
  • Milestone 1 now uses the month format for better clarity.
  • Based on the actual situation, I re-evaluated the duration of Milestone 2 and adjusted it to 1.5 months.
  • I have aligned for total costs / FTE * estimated duration, and now they are approximately consistent.
  • The total costs have been reduced by 2,000 compared to before.
• Yes, I am aware of Avail. Melodot is quite different from it in terms of data arrangement, distributed generation, and handling of the "the minimum number of honest light clients".

[Noc2]

Thanks for the quick reply and update. I will mark the application already as ready for review. But I need to spend a little bit more time looking into it. One question that I currently have is: do you think Melodot could potentially be a parachain, and what issues might you face in this regard?

[keeganquigley]

Thanks for the application @DarkingLee, your whitepaper link is asking me to log into a notion account. Is there a public link where I can read it?

[keeganquigley]

It also reminds me of the old proof-of-capacity project Signum (formerly Burstcoin), combined with Chia's proof-of-space. Can you explain who would be the primary users of this project once it is complete?

[DarkingLee]

Yes, there are various implementations of proof-of-space / proof-of-capacity. The difference lies in the fact that Melodot utilizes them to store availability data, so the primary users of Melodot are rollup applications.

[DarkingLee]

Thanks for the quick reply and update. I will mark the application already as ready for review. But I need to spend a little bit more time looking into it. One question that I currently have is: do you think Melodot could potentially be a parachain, and what issues might you face in this regard?

Melodot is not well-suited to directly function as a parachain, but rather as a parachain through a "data availability bridge", essentially because as a decoupled data availability layer:

• It operates on a different security model. For instance, on the consensus layer, GRANDPA reaches agreements on chains rather than blocks, which is useful in extreme cases to ensure fast and secure finality, but also has the potential to bring multiple blocks to finality at the same time. The data availability layer, on the other hand, expects a uniform finality, which would otherwise introduce uncertain transaction delays for rollup transactions in the settlement layer. In the long run, Melodot needs to have a more suitable finality gadget. In addition, the data availability layer requires many changes at the network layer (which is still an open research area). These determine that Melodot is not well-suited to directly function as a parachain.
• The purpose of the data availability layer is to eliminate the reliance on the "honest majority" to secure data availability even in the case of a 51% attack, so I think it is a Muda to use it directly as a parachain.

As Melodot matured, we used the Data Availability Bridge as a parachain. It was designed as a neutral bridge (allowing other data availability layers), and other parachains acted as settlement layers, getting data availability guarantees from Melodot parallel chains and "secure interoperability of settlement layers" from the security of polkadot.

[DarkingLee]

Thanks for the application @DarkingLee, your whitepaper link is asking me to log into a notion account. Is there a public link where I can read it?

I reset the link and now it doesn't need the login anymore.

[keeganquigley]

Thanks @DarkingLee, a fascinating read, and I appreciate the detailed comparison to Avail in your whitepaper.

• Are there any potential downsides to this model? For example I read that Chia's proof-of-time method was criticized for possibly shortening the life span of solid state drives due to the intensity of write activity.
• I don't see anything specific to substrate in the whitepaper except for the fact that the consensus has a similar two-phase finalization mechanism. Can you briefly elaborate on how you came to see a need for this in our ecosystem?
• After this grant is complete, how do you plan to fund the future plans for an SDK?

Thanks!

[DarkingLee]

@keeganquigley Thank you for your feedback, sorry for the late reply.

• Chia-style proof-of-space requires an initialization process called plots. This process writes data to the user's storage device and consumes significant resources. However, after this initialization, the resource consumption is minimal, specifically in the case of Melodot, it is less than that of a full node. The criticism of Chia, in my opinion, primarily revolves around filling users' disks with useless random data.
• I have been focusing on the development of social networks and reputation systems (implemented through Substrate), and in this process, I have identified some fundamental problems that have yet to be solved. For example, transaction ordering is not crucial in social networks, but in DeFi, significant costs are incurred to achieve fair transaction ordering. Under blockchain technology, they are given the same level of security. This is not an issue that can be simply solved by scaling alone. To address this, we conducted extensive research. After multiple design attempts, we decided to adopt Rollup technology to solve this problem. I aim to decouple the data availability layer and sequencer in the Polkadot ecosystem through parachain, where Polkadot's high security provides the settlement layer with security and scalability. Of course, further research and implementation are still required, however, I hope that at least through the data availability layer, bridging parallel chains with DA, and the SDK, we can bring another vast possibility space to the Polkadot ecosystem.
• We have a semi-annual plan, and once this grant is complete, we will initiate a community through a DAO to seek funding from VCs within the DAO framework. Considering the current market conditions, we have identified alternative solutions: leveraging the DAO's economic system to drive project collaboration and obtain a small amount of initial funding. Afterward, we will secure early reliable funding through a method called Quadratic Launch, which combines elements of an IDO and quadratic funding. The initial tokens will be allocated to the donors of quadratic funding. We have a detailed plan that includes different stages, financial planning, product roadmap, and more.

Thanks!

[keeganquigley]

Thanks for the thorough answers @DarkingLee I think it would be nice to see proof-of-space concepts working in substrate, and hopefully the pallets will help other teams who want to implement it as well. Therefore I'm happy to go ahead and approve.

[Noc2]

I'm sorry for not getting back to you sooner. To be honest, my biggest concern here and with the application is that you are trying to do too many things at the moment. But I'm happy to approve it since some of it might definitely be useful for other projects.

[DarkingLee]

@Noc2, Thank you for the review, and I understand that you must have been quite busy lately. Your feedback is valuable to me, and I will definitely take note of your concern about trying to do too many things at the moment.

[takahser]

@DarkingLee thanks, you've clearly put a lot of effort into the whitepaper and the proposal - it's well-written and contains interesting aspects, both from an economical and game-theoretical as well as technical point of view. It's the first time I've seen the concept of price elasticity applied to a web3 project, I've never thought of that before but in retrospect it seems obvious:) Anyway, happy to approve here as well.

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[burdges]

The current data availability layer scheme requires the assumption that the network has at least the minimum number of honest nodes.

This statement is true.

However, due to the need to prevent data retention attacks, the samplers are required to be anonymous, making it difficult to measure the number of samplers.

Polkadot does not require separate samplers for availability. The validators all "sample" exactly the one piece they hold themselves. Intersection of 2/3rd honest and 2/3rd claiming availability, says 1/3rd really are available, which suffices for reconstruction.

In other words, 1d RS has a better undecodable ratio, aka adversary must hide 2/3rd to hide anything, while a 2d RS permits hiding a small chunk of the block if the adversary hides only 25%, which further increases sampling requirements.

We do "sample" for validity in the approvals protocol, which includes proving correctness of the available data, but that's an separate concern. We do assume roughly a synchronous gossip protocol for approval assignment announcements though, but we do not require anonymity when sampling for validity, thanks to the no show system.

At the same time, samplers are more concerned with data related to themselves, resulting in an uneven distribution of total active samplers over time.

Ain't clear what you mean here, but it's evenly distributed among the nodes who claim to hold their chunk.

Aside from an undecodable ratio meshing cleanly with our security assumptions elsewhere, we abandoned wider sampling ideas used by Celestia like fishmermen or watchtowers because we concluded there was no mechanism for incentivizing correct behavior. We know validators can be incentivized, although this turns out nastier than one likes.

I've not looked into the rest but this paragraph jumped out at me, so figured I'd comment here. Carry on :)

[DarkingLee]

@burdges Thank you for your comment.

1. I greatly appreciate you sharing Polkadot's design, it indeed sounds intriguing. Polkadot's solution certainly seems elegant. However, there are fundamental distinctions between Melodot and Polkadot. Melodot serves as an independent DA layer, designed to cater to the settlement layer and rollup applications. The "settlement layer" in itself is another chain that's loosely coupled with the DA layer, and its security does not rely on 2/3 of honest actors from the DA layer. This presents additional design challenges for Melodot.

At the same time, samplers are more concerned with data related to themselves, resulting in an uneven distribution of total active samplers over time.

2. The crux of the matter here is that we don't rely on validators having data sufficient for decoding. Instead, we depend on a significant number of light clients randomly sampling across the network. This strategy has the advantage of considerably increasing the data payload of each block but requires proportionately more sampling nodes to support. The design can be challenged when the number of samplers for each block becomes inconsistent. For Celestia, I believe they might be facing similar design decisions. And Polkadot seems to have no such worries :)