For Dev Protocol to be compatible with Layer2

Proposals
#1

Summary

Suggesting counterplans for Dev Protocol to be compatible with Layer2.

Component Summary

Although we’re sure that Dev Protocol will be compatible with Layer2, we’d like to hear your opinions on the following points.

[ To which Layer2 Dev Protocol should be compatible with?]

  • We’re considering zkSync or Optimism as a candidate.
  • We’re not considering the combination use of plural L2 solutions.

[How Dev Protocol can be compatible with Layer2?]

  • We’ll use L2 as main net instead of adopting the combination use of L1 and L2.
  • After the transition to L2, the maintenance for L1 protocols will be suspended.

Motivation

Currently, Ethereum has an issue on scalability, which indicates its low processing performance.
Since Ethereum has a small number of transactions to process per second, people have to pay more commission due to the network congestion caused by the increase of operating applications on Ethereum. Layer2 would be one of the solutions for it.

What’s Layer2?

Briefly speaking, Layer2 is a technology to improve transaction process on Ethereum and to reduce the commission.
If Dev Protocol is compatible with Layer2, the issue of price jump in various transactions would be solved.

Details

The following table shows examples of Layer2:

Name Rollups Smart contract Contract Language Supporting Tool
Loopring ZK-Rollups X - -
Optimism Optimistic Rollups ✓ Solidity Truffle, Waffle, HardHat
zkSync ZK-Rollups ✓ Zinc Zargo

What’s Rollup?

Rollup is one of the scaling technology used on Ethereum. After executing transactions outside L1 (Ethereum), fast and low cost transactions can be realized by submitting organized transaction data or evidence to L1 as well as verifying at L1, while L1 security is maintained at the same time.
Rollups have ZK-Rollups that verify the validity of transactions by utilizing zero knowledge proof as well as Optimistic Rollups, which functions based on the premise that valid transactions are executed (unauthorized transactions are not executed), without necessarily bringing all the transaction data to L1.
ZK-Rollups have an advantage in taking less time for the completion of transactions compared to Optimistic Rollups, although the difficulty in the implementation of smart contract is one of ZK-Rollups’ shortcomings.

One of the merits of zkSync is its fast withdrawal of token from L2. Optimistic has an advantage in using solidify, assets so far, as well as knowledge gained from Truffle and Waffle. Keeping the transition cost low is another strong point of Optimistic.
Since character strings cannot be used freely in the current version of Zinc, a contract language for zkSync, there would be some technical barriers at the time of creating Property Token. Therefore I think Optimistic is a better choice.

Reference to L1’s storage data and smart contract methods cannot be executed with L2 in default. Strictly speaking, they can be done with Optimistic, however, in that case, there would be major limitations e.g. (1) the gas fee costs much, (2)advantages of using L2 are minimized, (3) it takes 7 days to reflect the results.
All things considered, we’re thinking about newly creating Dev Protocol at L2, and supporting users’ migration of tokens such as DEV tokens as well as Property tokens. Since the storage information of L1 is reset when moving to L2, staking should be executed again at L2 after migrating DEV tokens and Property tokens from L1. In other words, we would create another Dev Protocol with cheap gas fee.

If you have any comments on it, please let us know.

Agreed Collaborators

aggre

Missing Roles

None

Compensation

N / A

References

None

2 Likes
#2

I feel like it’s pretty clear what the best options are here. Optimism seems to be ahead and more developed. If the plan is to implement L2 solutions right now Optimistic Rollups should be the one used.

After a while, if Zk-sync catches up and their solution is better, maybe migrating to zk-rollups could be ideal, if Optimism continues with current problems.

1 Like
#3

Main claim

Reasoning

  • $DEV needs more legit demand
  • Retroactive Public Goods Funding gives DEV burning budget if we are good for Optimism
  • Retroactive Public Goods Funding indeed requires “project token system” to make their Results Oracle budget useful for non-cash-rich projects.
  • $DEV can be an easy gateway for Retroactive Public Goods Funding users

Quotation

For whom busy to read the Retroactive-blah-blah, read this screenshot and think about the ugly future that so many FOSS-project-DAOs are opening their Telegram chat and doing scammy promotion. That’s a hell (And that’s happening now.)

Screen Shot 2021-08-01 at 11.12.05
Screen Shot 2021-08-01 at 11.12.05746×693 49.1 KB

The best solution would be “stake $DEV and get money without doing DAO/Telegram/Promotions :)”. That’s the future of humankind.

Conclusion

  • People who wanna earn more via FOSS get richer with Retroactive Public Goods Funding, and Optimism ecosystem would be better together
1 Like
#4

Yes, the vision and concrete plans that exist on Optimism are a good fit for us as well, I guess that’s one fact.

And please refer to this article, which also mentions Retroactive Public Goods Funding :slight_smile:

#5

One of the biggest concerns in this proposal is using L2 as the mainnet, in other words, a rollup-centric protocol.

DEV has an L1-L2 bridge (probably), but the feasibility of an L1-L2 bridge for Creator tokens is still unknown.

Both zkSync and Optimism support interaction with L1, but zkSync’s is laggy and unstable, and Optimism has the advantage. However, Optimism has a 7-days interval, and until the L2 ecosystem is sufficiently expanded, it will continue to be more inconvenient than L1 in terms of composability. However, Dev Protocol can accomplish any operation with very low gas fees.

#6

I (as well) am struggling to make a smooth intergration between L1 and L2. I agree that L2-optimized dapp is an optimal move so far (and will be for a long time). What makes it hard is 1) fetching state data (esp. whitelist and owner info for ACL) from L1 to L2 2) consistent minting on L2 with sharing the same token between L1.

Optimism v.s. zkRU discussion would be broken down to the priority of 1) demand aquisition for $DEV 2) money circulation on the network 3) ultimate technical legitimacy.

For demand, Retroactive Public Goods Funding’s reward would be very cool for $DEV. We need a lot of work for being rewarded by the Results Oracle, although, it’s much better than nothing. If it is on zkRU, there would be no reward.

For money circulation, Optimism will be good soon and zkRU would take more time.

For tech, zkRU could be better (except for proving cost) but short-term adoption could be prior.

P.S.

Project Token idea of Retroactive Public Goods Funding requires selling a token per each FOSS project(!). This is legally risky and communication is more cumbersome than normal FOSS (yes, the FOSS maintainer is inherently hard and investor relation is also hard. It’s rubbing salt into the wound). Furthermore, anonymous token sale is harder, one may need DID and track records to accomplish it.

But $DEV doesn’t have those downsides. Write FOSS, get staking, that’s all. No sale and no DID. Much quicker adoption of Retroactive Public Goods Funding and Effective Altruism will come true. That’s my take.

#7

Hey @0xkonata I agree with the optimism bit. But I’m struggling to understand how would Retroactive Public Good Funding would increase the demand for DEV tokens.

I couldn’t understand the implication here.

The main benefit from L2 solutions to the Dev Protocol ecosystem in my point of view would be competition between Creators.
Reducing the costs of staking would make it more fluid, allowing Patrons to Reward projects that are doing good or benefiting Stakers more, and penalizing others who are either not active or being negative to the ecosystem from the Staker perspective.
We can easily see how this would move the rewards going to projects that have more time to - be active and reward stakers. This would also mean that the ‘Proof of Creation’ idea that is being talked about could be really viable and the Dev Protocol ecosystem would converge to an ecosystem where Active and Beneficial (financially) projects are being funded.

If there is at least one project that is willing to the DAO/Telegram/Promotions, this is no longer a competition, everything else being constant. Stakers will reward those that reward them.

#8

Hi Pdot, thanks for taking time for response.

For demand in detail

The assumption here for the demand of $DEV is “burning pressure” where the reward acceptance contract automatically do so. In other words, a contract buys back $DEV and burn it. The budget for buying back is the reward from Retroactive Public Goods Funding of Optimism.

For implication in detail

The implication I intended to tell by the screen shot was the pitfall of the third bullet point “project token” idea of Vitalik. The Retroactive Public Goods Funding rewards each FOSS project retroactively so that all FOSS projects have to wait and pray if they can get reward from Optimism (The decision will be done by arbitrary governance.) That probabilistic rewarding will be inconvenient and so Vitalik might have proposed the token issuance idea for acrueing potential reward earlier via transferring risk exposure from FOSS developers to investors. It has a pitfall that it requires FOSS developers to deal with investors and the culture where FOSSs have execuse to sell token will gather scammers to sell useless FOSS project tokens. That’s where I intended by using words “$DEV will be a gateway”.

Nitpick

  • If Results Oracle doesn’t like benefitting the holder of $DEV premint, it would be negative factor to get reward from it.
  • If Results Oracle didn’t know $DEV and bypass it, each FOSS project will get direct reward while they also get $DEV reward.
  • So it means Dev Protocol is helping acrueing reward earlier and helping appealing for Results Oracle (yes, some projects are modest and just heads down. Proof of Creation must reward creators rather promoters.)

Please don’t hesitate to ask more. It’s high context.

#9

Thank you for your responses, @0xkonata !

Oh, now I got it, so the funds are exogenous in this case. This is where I was getting confused. What you’re proposing then is to shape Dev Protocol so that it is eligible to receive funds from 3rd parties?

This still falls under the Altruism based category for funding public goods doesn’t it?

The same thing happens on the Dev Protocol ecosystem, stakers are taking all the risk here. Projects that mitigate that risk by providing more value for stakers, get more rewards (Stake).

Sorry, even though it is becoming more clear to me, I still don’t get the idea. Are you proposing a complete remodeling of the Dev Protocol tokenomics/ecosystem to fit the Retroactive Public Goods Funding system?

We have to keep in mind that Dev Protocol’s system is unique, it’s the only system where Patrons don’t need to be Altruistic to help projects. Yes, it ‘forces’ OSS projects to compete for those funds, but I think that’s expected, it might bother some, but that’s how a free market works, and more importantly, monetizing their own community is expected - the Decentralized Creator Economy solution for monetization.

If it is a parallel use case of Dev Protocol, by allowing the Optimism fund to get in and burn tokens. Then that would be really cool, I just want to understand it a little bit more.

#10

What you’re proposing then is to shape Dev Protocol so that it is eligible to receive funds for 3rd parties?

The actual proposal would be an “independent contract” which has receive() function to buy $DEV in $ETH from Uniswap and just burn the $DEV.

This still falls under the Altruism based category for funding public goods doesn’t it?

No. There’s a fee pool of Optimism where it is acrued from gas consumption and MEVA. So it’s not a donation. It’s kinda retroactive dividend. It can be called an investment from the Results Oracle (= professional committee or Optimism community), or Effective Altruism. In other words, stakers gonna get benefit from $DEV burn. $DEV is pseudo-deflational currency under this exogenous funding circumstance. All stake holders could be egoistic rather altruistic but still system would be maintained.

The same thing happens on the Dev Protocol ecosystem

Um, kinda no. First, stakers’ risks are mitigated as I mentioned above. Second, the flaw of the Vitalik’s idea isn’t about the risk transferring, it is indeed a good invention I believe. The real problem is necessity and the prerequisite existence of “project token sale event” where Dev Protocol abstracted-away from entire system.

Why does the sale matters? - Because token sale is more legally & emotionally sensitive than staking reward. FOSS maintainers are inherently busy and they should not be bothered by the investor relationship. (Futhermore, if FOSS developers wanna go anonymous, the prerequisite sales event will be soooo huge burden. It’s hard to sell token anonymously. Waiting for the decentralized-ID? No way, Dev Protocol can bypass it.)

If it is a parallel use case

Yes, this is totally parallel, independent, and conservatively incremental enhancement to the existing protocol. Just a buy back contract and exogenous income. That’s it.

The deflational token staking and its reward is the smartest solution I believe. - And finally I can conclude for the main topic of this thread - zkRU doesn’t offer such opportunity (yet).

1 Like
#11

@0xkonata Awesome! thank you for your response. I understood what you’re trying to say, it is really a cool idea! If implemented and if we manage to get their attention it would be a game changing enhancement of the DEV tokenomics.

I like the idea of creating some complexity and some deflationary forces into the tokenomics.
btw have you seen this discussion? [RFC] Separation of utilities and rewards, a new built-in token with a fixed supply
Having this deflationary force - burning tokens - outside of the Governance token pool would make this super cool.
Thank you for these comments!

Sorry for changing the main subject :stuck_out_tongue: also, thanks for letting me know that zKRU doesn’t offer that yet, I didn’t know.

1 Like