Roadmap for high throughput

Development
1

hey, so the official roadmap doesn’t talk much about how exactly neptune plans to scale up, i did read the blog posts but i just want to clear some stuff up

lighting network is something i see mentioned a lot, however just taking a look at bitcoin, it’s clear lightning network has flopped and has it’s own issues. not only does it not support programmability, but it requires on-chain tx’s to open channels which is just annoying for users and neptune’s L1 has so little throughput it can’t support a large number of people opening channels. current mainnet tps is i believe ~ 2 with a 10minute blocktime making this one of the slowest and least scalable L1s in crypto right now.

zk rollups are a solution that seem to be gaining adoption however there’s no data availability layer on neptune so you’d need to trust another chain. not only that but using PoW which can be more easily re-orged in the short term + ultra fast zk rollups with critical financial apps seems to be a bad combination (that’s why zcash is adding proof of stake elements to create some sort of finality can be guaranteed)

im just wondering if the team are fully thought through what neptune running the future of the entire financial system will actually look like (so 100k+ TPS, financial apps running on neptune, incredibly easy user experience etc) and if there’s been an in-depth breakdown somewhere as I can’t find one.

simply just saying neptune will use lightning network, with lightning network being an incredibly flop with magnitudes of less activity on it compared to ETH L2s and other L1s etc has me worried. i’d love to hear what the full stack of neptune long term will look like at a high level, lets take one of the most used apps in crypto hyperliquid, a decentralized perp dex. Assuming one were to build a private version on neptune, how would it work theoretically and guarantee safety for transactions on with sub-second latency and high throughput with 9-10 figure USD trades being executed.

2 Likes
2

I think these are excellent questions. Also, fully agree with Lightning being a disappointment.

Would like to mention MINA protocol here, which has many similarities to Neptune. MINA is not quantum resistant and it relies on ZK SNARKs instead of STARKs. But both are L1 cryptocurrencies, relying on ZK proofs, and MINA already has succinctness due to recursive proofs. However, it too faces unsolved challenges with scalability (promises about L2 roll-ups have not yet manifested on MINA) and data availability.

1 Like
3

These are great questions. This is a great opportunity to put words towards answering them. That said, I do believe there are a few misconceptions lurking in your questions so I will be addressing them as well.

Lightning

That’s up for debate. There is no universally agreed-upon meaning for “flop”. The numbers are there for placing the network among the top 100 networks on coinmarketcap.com. I use it from time to time and if it does not work (which is surprisingly rare) I never use on-chain BTC as an alternative.

The Lightning Network is not living up to some of the more optimistic expectations held by proponents at the beginning, of scaling sovereign self-custodied money up to billions of users. I think this goal was a pipe-dream from the start and if that’s the standard by which you judge and dismiss the Lightning Network you risk underestimating the technology’s massive impact.

Lightning – the technology, not the current network – is a big deal because there is an economic cost to having trades not take place when all parties agree to the terms. Lightning fixes this: it allows trades to take place

  • without trusted intermediaries, often a blocker preventing trades from being completed;
  • at the speed of light, and slower speed limits frequency;
  • without interfering with each other, as Lightning transactions do not compete for scarce blockchain space or other scarce resources.

In my eyes, the reason why the Bitcoin Lightning Network seems to be not taking off is because

  • there is nothing to trade Lightning-BTC against, except on-chain-BTC;
  • most channels are relatively small, tailored to micro-transactions as opposed to macro-transactions.

There is one exception to the second bullet point (and simultaneously, from the right perspective, to the first) where the Bitcoin Lightning Network has tremendous potential, if it has not been implemented to this effect already: transactions between cryptocurrency-exchanges. When you send Bitcoin from Coinbase to Kraken, there is no need for those Bitcoins to touch the chain. It means that you will be able to make a trade on Coinbase, pull capital over to Kraken, trade there, and bring it back, all in under 100 milliseconds. Tell me that is not a big deal.

Smart Contracts on Neptune Cash versus Ethereum

In regards to smart contracts, important questions that distinguish Neptune Cash from Ethereum are: 1. Where does state live? 2. Who executes the smart contract?

  • Ethereum: state lives in VM memory, which is replicated across all nodes; and all validators execute
  • Neptune Cash: state is committed to (think Merkle root) and the commitment lives in a UTXO on the blockchain; to execute a smart contract you need to:
    • a) track the UTXO (it is a private ledger after all)
    • b) satisfy spending policy (or more appropriately named: execution policy)
    • c) prove correct state update

Neptune Cash can emulate public-state+anyone-can-update smart contracts (Ethereum-style): by a) requiring the UTXO-tracking information to be part of the transaction that updates the smart contract state, embedded in the announcement; b) enforcing and anyone-can-spend policy; and c) including the complete state update in the announcement as well.

An alternative modality that Neptune Cash also supports is a smart contract whose logic and state is known only to participants of some overlay protocol. Participation can be opt-in or permissioned. The blockchain is used to pin commitments and settle potential disputes. The commitments that make it to the blockchain are indistinguishable from regular payments. The protocol participants are responsible for disseminating data; the blockchain guarantees that they cannot lie about it. You can put the data on the blockchain but that’s more expensive because of fees.

I think Ethereum-style smart contract are great for bootstrapping a marketplace. But the need for transparency everywhere limits the trades, strategies, products, etc. that people want to deploy. Engagement with transparent smart contracts exposes them to MEV, other kinds of frontrunning, leaks corporate secrets, etc.

ZK-Rollups

Public-access overlay protocol style smart contracts play ball very nicely with zk-rollups. One central party aggregates a bunch of transactions at high frequency and periodically commits to an updated state on the blockchain. That central party does not need to be trusted because that can only update the state commitment with a zk-STARK proof of integral execution. And nor do they need to be trusted for availability because an escape hatch mechanism is built into the state commitments. This conception of public-access overlay protocol smart contracts blurs the lines between Ethereum-style smart contracts and rollups.

At the same time I think overlay protocols on Neptune Cash are well suited to address the big problems with rollups on Ethereum that I see, which is the segregation of capital. When your capital is locked in one rollup, you cannot use it to trade on another rollup. Neptune Cash is the ideal platform to address this deficiency because of UTXOs and zk-STARKs. Put together they enable a Lightning network between the centralized-but-untrusted overlay protocol operators capable of settling arbitrary disputes.

Proof-of-Stake

To the extent that staked capital can generate finality or some sort of assurance against revision, you can emulate that without having to bother with proof-of-stake. The obvious caveat is that staked capital is incapable of insuring information worth more than the capital that is being staked.

1 Like
4

Thanks for replying but I still don’t understand certain decisions.

To the extent that staked capital can generate finality or some sort of assurance against revision, you can emulate that without having to bother with proof-of-stake. The obvious caveat is that staked capital is incapable of insuring information worth more than the capital that is being staked.

If every single rollup is going to need to effectively be it’s own PoS chain to protect against reorgs then what’s the point of the L1? The securiy it gives will be pretty weak. The PoS network on each L2 will hold the real power and that’s what all the users will trust.

Not only that but that if every L2 on neptune is proof of stake, then that defacto makes neptune proof of stake as all of it’s economic activity will be secured by those L2s. So why not just make life easier for everyone and move it to the L1? That way L2s can just take advantage of the total stake on the neptune L1 rather than each one individually worrying about it’s own securtiy.

I understand you guys dislike PoS, but it seems like you guys are proposing a PoS/PoW hybrid network - just less secure and more messy by telling layer 2s to be proof of stake themselves to protect against reorgs?

5

With regards to high throughput, I think it may be worth studying what Quai Network is doing, as a high scalability POW based blockchain. They have been working to improve POW characteristics for years. I will start a thread with some of their papers.

6

from what I know, quai is an improvement, but that’s not good enough

big apps need actual finality with zero chance of a re-org happening and even with quai type PoW, L2s will still need some PoS mechanism to make large traders feel safe that there won’t be a reorg if someone decides to build a perp dex on neptune / another big app.

which begs the question, if every L2 will need PoS to guarantee finality - why not just add that to the L1 which basically is the same thing, but simpler and more secure.

7

You misunderstand. I am not proposing L2s use proof-of-stake to generate finality. I am suggesting that initiators or beneficiaries of transactions that have an interest in insuring finality pay for it themselves rather than offloading the cost on the other participants of the protocol.

  1. Finality is a Myth.

What does it take to revert a transaction on a proof-of-work chain? An alternate view of history with more work.

What does it take to revert a transaction on a proof-of-stake chain? An alternate view of history with more stake.

Of course, stakers stand to get slashed if they entertain and sign off on multiple views of history. They don’t because it will cost them. How much it costs them depends on how much staked capital they stand to lose and on how much they stand to gain from reverting or revising history. There can be no finality of histories that are profitable to overturn.

  1. Staked Capital Can Insure Transactions.

What do you need to insure a transaction against the event that it is reorganized away? You want the commitment from the counterparty that they will guarantee through whatever means they possess that the insured transaction will also be part of the new, revised history. And if they fail to achieve that, you want a credible guarantee to receive some predefined payout. And if we are assuming no recourse to law and no trusted escrow parties, then this insurance mechanism is still achievable through a smart contract for staked capital that evaluates the release policy automatically.

If your position is that an insurance mechanism like this, separate from but in addition to a proof-of-work consensus mechanism, is messier, more complicated, and less secure than a singular proof-of-stake protocol that does both insurance and consensus, then … I don’t know what to say besides I might take you seriously once you finish the implementation.

  1. Misc.

In light of my clarification regarding proof-of-stake versus insurance, let me reinterpret the question as follows before responding.

To activate the insurance mechanism you still need to stake capital through an on-chain transaction. This is where the qualitatively different security guarantees of proof-of-work versus proof-of-stake come into play:

  • In proof-of-work, the cost of reorganization grows with the depth of the reorganization.
  • In proof-of-stake, there is a one-time cost and once that is met, reorganizations of any depth are on the table.

Therefore, in proof-of-work protocols, there is a way to derive not just how much capital should be locked up but also how long it should be locked up for in order to credibly meet a target value of transactions to be insured. In contrast, proof-of-stake protocols are incapable of insuring transactions whose values exceed the sum total of all locked up stake.

8

So your thinking that generally dapps will all have their own in-built insurance mechanisms for their users?

This seems like something that could turn into a mess.

E.g. some apps will likely not due insurance properly / have different rules for how they pay insurance and assets from those apps could be used in other apps which are used in other apps etc. and all in a variety of complicated ways meaning that a reorg happening could cause a huge cascade effect on a defi ecosystem even if insured.