pocs-proposal

[Purva-Chaudhari]

Proof of Contract Stake

Project Abstract

Blockchain technology, with the introduction of Ethereum protocol, impacted the ecosystem by introducing the concept of smart contracts. These self-executing contracts have enhanced the functionality and versatility of blockchain networks, opening up a wide array of decentralized applications and use cases. However, despite this pivotal development, there is absence of a consensus mechanism that places smart contracts at its core. Recognizing this critical gap, we present Proof of Contract Stake (PoCS) – The First Developer Centric Consensus.

PoCS is an innovative staking system that leverages contract gas history to select block producers. PoCS integrates elements of both proof-of-work and proof-of-stake. We have introduced a novel concept of 'code-mining' that incentivizes developers to actively participate in securing the network. By aligning the interests of developers with the network's security, PoCS introduces a dynamic where smart contract creators play a vital role in consensus. In addition, PoCS implements a system of 'stake scoring', taking into account factors such as contract age, reputation, and gas utilization. This design not only fortifies the network against collusion type attacks but also ensures a fair and secure environment for all participants. It also addresses a longstanding concern in blockchain consensus models – the 'nothing at stake' attacks . By introducing a non-fungible, non-transferable unit of scarcity for staking, PoCS effectively mitigates this vulnerability, making it a secure and reliable network. In addition, the stake accumulation attack in PoCS is time constraint and patterned which can be easily detected. This escalates costs over time and cannot be expedited with any external resources.

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 Polkadot (USDC & USDT) or BTC 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)

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[Purva-Chaudhari]

I have read and hereby sign the Contributor License Agreement.

[Noc2]

Thanks for the application. Could you change the denomination of the cost to fiat? We no longer denominate grants in BTC. See our guidelines and terms and conditions. Additionally, we don't pay teams any upfront payment. Furthermore, some of your milestones only contain the default deliverables (0a. to 0d.). Could you add what you plan to deliver as a separate point with as many details as possible?

[Purva-Chaudhari]

@Noc2 Thanks for the comments. I have revised with the requested changes

[keeganquigley]

Thanks for the application @Purva-Chaudhari looks super interesting. I see the outline of core functionality for the pallet, but could you include the anatomy of the validator reward contract as well?

[Purva-Chaudhari]

Thank you, @keeganquigley I have added the notion of how it will look like. Let me know incase of any further description needed

[keeganquigley]

Thanks for the changes @Purva-Chaudhari looks intriguing and I'm always interested in new/different consensus models. Happy to approve.

[Purva-Chaudhari]

Thank you @keeganquigley , Looking forward

[semuelle]

Thanks for the application, @Purva-Chaudhari, and sorry for the long wait. This is interesting work. It seems that you have been working on this all by yourself so far, is that correct? Have you discussed this idea with the community or like-minded researchers? It would generally be nice to gauge the sentiment of others when it comes to such far-reaching projects. I'm not an expert on consensus mechanisms, but while I very much see the upside of aligning block production with network use, I also wonder if this coupling might cause disadvantageous consequences, e.g. by gaming the system or through misaligned priorities of validators and contract developers. Do you have any thoughts on that?

[Purva-Chaudhari]

I'm not an expert on consensus mechanisms, but while I very much see the upside of aligning block production with network use, I also wonder if this coupling might cause disadvantageous consequences, e.g. by gaming the system or through misaligned priorities of validators and contract developers. Do you have any thoughts on that?

Hi @semuelle Thank you for your points. Here are some insights on them -

While it might seem more like a gamified consensus, our motivation to design a developer-centric consensus model is to address the gap between smart contracts and existing reward systems and an alternative to favoring individuals with higher stakes or monetary resources.

Regarding misaligned priorities of validators and contract developers, we have introduced a trustless per-transaction reputation system. This avoids such deviations, aligning incentives with meaningful and inventive contributions as well as adding a defense design for developers attempting to game the system by creating malicious contracts. With PoCS as a staking module and BABE’s block production module of random validator assignment avoids validators misalignment on influencing block production.

We have discussed such vulnerabilities (we termed them as “collusion attacks”) pertaining to misaligned priorities of validators and developers to game the system to increase their block production and established an effective design to mitigate this.This helps in aligning incentives and ensuring fairness. Reference - Contract Reputation

We have also ran simulations on how it would look if ethereum had Proof of Contract stake, and the results we obtained so far convinced us to continue to develop it. The results have demonstrated PoCS’s resilience to hypothetical collusion attacks while consuming massive time for an attacker to carry out amidst honest transactions (as network resources are scarce and it takes time to accumulate). Additionally, it introduces a new aspect of creativity to the blockchain space which we think has not been yet explored. PoCS can be an effective environmental-friendly variant to existing consensus and such a system will hold accountability for the quality of smart contracts that a developer is writing and also on the bright side can encourage developers to run validator nodes also.

Moreover, our reason to choose polkadot for developing it has further been the aligned foundation it provides to develop such a consensus, like wasm builds, runtime upgrades and a parachain environment to provide value to the like-minded community of developers. We still continue to research more on furnishing the protocol and tackle any unknown vulnerabilities with the support of this ecosystem.

[Purva-Chaudhari]

Thanks for the application, @Purva-Chaudhari, and sorry for the long wait. This is interesting work. It seems that you have been working on this all by yourself so far, is that correct? Have you discussed this idea with the community or like-minded researchers? It would generally be nice to gauge the sentiment of others when it comes to such far-reaching projects.

The research started as a passion project between a team of 3-4 members. In the early stages, we conducted high-level discussions about our consensus with individuals from various blockchain communities. The response has been encouraging, particularly from developers who expressed keen interest in the innovative aspects of developer incentivization for their contributions (which we termed as “code-mining”). However, we acknowledge a certain level of ambiguity among others in grasping the full scope of the consensus. To address this, we've decided to advance the project by developing a reference implementation atop Polkadot/Substrate, aiming to establish an alpha-stage consensus. This approach would allow us to actively involve and build a research- community for the consensus. Simultaneously, we are in the process of onboarding a professor, to enhance the research direction.

Additional Links

Our Goals via PoCS
Simulating PoCS on Ethereum

Please let us know if further information is needed. Thank you

[Noc2]

Thanks for the update. I have another question: Could you explain how you prevent DDoS attacks or where can I read more about it? Also, the cost/FTE ratio is different for different milestones at the moment. Why is this the case? Would you be willing to reduce the total costs?

[Purva-Chaudhari]

Thanks for the update. I have another question: Could you explain how you prevent DDoS attacks or where can I read more about it?

Hi @Noc2,

Introducing a per-transaction stake score helps prevent scenarios where a massive influx of transactions could lead to DDoS issues (which we call as collusion attacks). These transactions are only considered valid to be added to a block if they meet the existing transaction validity check on Substrate.

Here is some insight on how its done

• Using the trustless contract reputation, which reflects a contract's activity PoCS calculates a stake score for each transaction.
• PoCS will utilize the network's resource as a scarce resource to create a stake score. The transaction's weight (refTime) will be used to bond to a validator. The validity of a transaction and its addition to the block provide the stake score. It's at the discretion of the block producer to decide which transactions to include, based on their priority in the transaction queue.
• Since transactions incur weight fees, colluding validators and developers would find it costlier and more time-consuming to artificially increase the stake score.
• Our simulations on Ethereum have shown that PoCS provides resilience against a 10% and 20% block accumulation attack, preventing the achievement of a 51% majority stake.

In addition if interested here is a detailed documentation that provides detailed information on mitigating artificial stake inflation caused by collusion methods (which is regarded as DDoS attack) that can be initiated by a validator and its bonded contracts.

We tried to align the idea of a scarce resource by using the weights or time spent by a contract as a stand-in for PoW, where hardware is the limited resource, and PoS, where tokens and their tied-up market value are scarce resources.

Likewise, PoCS won’t likely cause halting of a node as it won’t conflict with any of Substrate’s existing weight model, since it’s just a staking module that creates bonds while mitigating the possibilities for artificial inflation of stake - which is expensive and is time constraint. This makes it massively time consuming/beyond computational limit to attempt such attacks

[Purva-Chaudhari]

Also, the cost/FTE ratio is different for different milestones at the moment. Why is this the case? Would you be willing to reduce the total costs?

The distribution of cost/FTE might look slightly uneven, however we have distributed the amount depending on the complexity of task in each milestone. Overall we are a team of 6, 3 of which are core developer and researcher which we have mentioned along with the profile and remaining 3 assist on task basis and contribute to our non-technical activities too. (we haven't explicitly mentioned this in proposal)

We have been working on substrate and trying to understand the relevant pallets to design our implementation based on which we defined-

• In our first milestone - we will be handling the contracts pallets (3 - 3.5 FTE)
• Our second milestone - is assumed to provide an end-to-end demo of pocs coupled with the staking part, where we handle babe, staking and contracts pallet. (Here we have 3-3.5 FTE)
• Our third milestone is adding a validator reward contract contract, adding it to the consensus and testing (3-3.5 FTE)
• And our last milestone was designed to make us ready for a alpha test chain which included e2e testing, documenting lite and yellow paper for the protocol (3 FTE)

We acknowledge that the research and concept may be relatively new and might not have widespread understanding or immediate adoption. As we validate our research through the development of the proof of concept, we are open to some negotiation-

We propose to adjust our last milestone - We will increase the weeks slightly for our milestone 3 and are open to eliminating milestone 4 as a separate deliverable for this grant. However we will still be aiming to accomplish it regardless by extending 2 more weeks with a cost of 8k (3-3.5 FTE) for the overall 3rd milestone and reducing the overall ask by 5K USD.

In parallel, we continue to research more on vulnerabilities, refine and extensions for further versions, we are happy to discuss and provide its updates along the grants

Let me know if this seems agreeable or if there are any other concerns, I will refine the proposal once finalised.

Looking forward!

[Noc2]

Thanks for the update and sorry for the late reply. Feel free to update the application accordingly. Given that you want to change the consensus, have you already looked at potential issues regarding becoming a parachain?

[Purva-Chaudhari]

Thanks for the update and sorry for the late reply. Feel free to update the application accordingly. Given that you want to change the consensus, have you already looked at potential issues regarding becoming a parachain?

Hi @Noc2 ,
Yes, we've designed PoCS to be interoperable with Polkadot parachain/relay chain environment.

Currently we are designing to extend it to be useful to parachains by working on a pocs-based collator selection process. Our next follow up proposals after the alpha test and completion of this grant includes building a simple pocs-npos interoperable democracy (bond based voting) and to be architecting pocs for collator selection (involving pocs-contracts_pallet, pocs-staking_pallet, pocs-collator-selection_pallet) which can bring trust-free selection. Moreover, while PoCS introduces changes to the conditions for selecting validators for block proposition, the foundation is rooted in the Babe + Grandpa protocols, following the polkadot family of consensus protocols.

As being the developer-focused consensus on Polkadot, it also leverages use of ink. We believe that once we complete our Proof of Concept and progress towards an alpha testnet, we'll be better positioned to make informed on how to grow within the Polkadot ecosystem based on the feedback from community members.

It's the first of its kind, focusing on developers and encouraging active engagement. We believe it will contribute to the growth and engagement of Polkadot's developer community and ink! DSL usage.

If there are any other specific issues that need to be addressed wrt to parachain let us know !

[keeganquigley]

Thanks for the updates @Purva-Chaudhari and sorry for the delay. I am happy to re-approve. Also, sorry for the inconvenience, but we just started requiring KYC/KYB checks for all potential grantees. Could you please provide the information outlined under this link? Let me know if you have any questions or issues!

[Purva-Chaudhari]

Thanks for the updates @Purva-Chaudhari and sorry for the delay. I am happy to re-approve. Also, sorry for the inconvenience, but we just started requiring KYC/KYB checks for all potential grantees. Could you please provide the information outlined under this link? Let me know if you have any questions or issues!

We have done the KYC have dmed you a small issue on matrix.

Thanks

[Noc2]

Sorry for the delay here. I'm also happy to go ahead with it.

[takahser]

Hi @Purva-Chaudhari. Not sure if this was already raised, but could you add the mandatory deliverables (i.e. Article and Docker) to your milestones?

[Purva-Chaudhari]

@takahser Thanks for pointing out. Updates done

[takahser]

LGTM now. I'll ping the rest of the team, since their approvals were dismissed by the document update, so no need to worry about that.

[Purva-Chaudhari]

Thank you very much!

[semuelle]

@Purva-Chaudhari, could you reach out to me via Matrix?

[Purva-Chaudhari]

@Purva-Chaudhari, could you reach out to me via Matrix?

Sure

[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! 🚀