Personally I am not yet convinced by most of the layer 2 solutions. Ethereum and Bitcoin have tried for years and spend millions of dollars on it but none of these platforms have yet seen any widely used layer 2 solutions.
Layer 2 in Bitcoin and Ethereum came about because they couldn’t evolve the baselayer fast enough (or at all) and hence had to invent this layer 2 thing. However in Tezos we have the advantage that we can evolve the base layer and due to that our team will spend a lot of time focusing on making the base layer scalable.
First, remember that you do not need to use the same node for baking and doing the RPC calls to compute the rewards. The computations could be done using another (archive) node.
Second, the tezos-node could definitely be augmented with another history-mode that would let the administrator set the collection point manually using an RPC call.
Consensus is a large area where more research and work is required in order to add a finality gadget that provides deterministic finality over an underlying block production mechanism.
Besides that we still need improvements on the higher level programming languages in order to make them easier to use. Ligo and SmartPy are currently getting there and will certainly help with normal developers writing and deploying smart contracts. On the research side Juvix and SCaml are looking interesting and my yield good results in the next 6-9 months.
Overall it’s important to acknowledge that Tezos is a working system, but is still far away from being able to be used by a large group of users and we need to make certain to stay ahead of the curve.
Q: Is Tendermint or “Tenderbake” currently the only finality solution core developers are currently exploring? Are there other projects being considered? Or is there a solution that you would like to see explored as a potential proposal?
Oher then horizontal scaling like sharding which is of questional utility so far are there not fundementle constraints to baselayer scaling past a certain point well below what would be needed long term? I agree with you on the concerns over L2 by the way.
Point 1 is certainly something to look into. One of the concerns with it though is that this could hurt small delegators that have < 1 roll, since the entire baker ecosystem could disable delegations and then small token holders can’t delegate anymore.
Enabling smart contract based payouts systems is something that would be possible with option B of baking accounts. This is because it will give bakers the ability to implement a contract that defines the logic for how rewards can be accessed. Most likely it would mean that delegators could choose to manually withdraw their rewards which may be a tax benefit on the jurisdiction (I’m not a global tax lawyer, but I know jurisdiction where this would certainly be the case and I think the US is one of them).
The Cryptium Labs baker is only running archive nodes, because disk space is cheap and we like to have all our nodes have the full range of RPCs available.
I think there are certainly bounds on base layer scalability, however we are nowhere close to them. Solana is doing super interesting work in optimising signature verification and their database layer and I think we can learn quite a bit from them. My estimation is that we can probably push the base layer to something like 1000 tx/s without massively sacrificing decentralisation. This is also a function of the fact that most people in the world have access to relatively cheap compute.
Actually another area is light clients. Once we have finality gadgets we need to spend a bunch of time building efficient mobile light clients in order to make wallets not have to trust the fullnodes.
Hotstuff and PaLa also look promising due to their simplicity and the pipeline-ing feature. However, for the moment we feel it’s more important to find solutions that tolerate more than one third adversaries.
A lot of energy and resources have been dedicated to high-level languages (HLL) over the past year. What is being done to make Tezos a better compilation target for these languages ? If we are going to be an ecosystem with multiple HLLs (as opposed to Ethereum which is almost totally dominated by Solidity), what can be done to ensure robust composability between contracts written in different languages?
What level of priority do you place on lowering roll size? What levels have been benchmarked?
What is DaiLambda currently working on? And when can we expect the first proposal from DaiLambda?
Are there groups other than Nomadic Labs, Cryptium and Dai Lambda working on Tezos core protocol development? Perhaps someone like the Cornell team that received a grant early on…
When do you guys think the first proposal injection with real money will occur on Tezos?
Outside of general participation in test networks. What could community bakers, developers, researchers, and enthusiasts do better to assist the decision making process for core development?
Going off of Jacob’s question regarding roll size. Back of the napkin how much could we reduce the current roll size before reaching a significant bottleneck in resources?
About the second point, we benchmarked down to 5k if I remember well (and it worked no problem but took more space than the current 8k), but the storage has changed since, so we should redo the benchmarks.
Understood thank you. I will dig into Solana further as my initial impression was it was roughly equivalent to sharding but instead of using native sharding it was providing interoperability with other chains each with their own strengths (thus similar to heterogeneous sharding) and they would provide the root shard consensus.
Another promising area into which Cryptium Labs may start looking in the future is to add a finality gadget. That way we could leave Emmy+ as it is and finalise blocks that are being produced by it. The advantage of this approach is that it enables to have fast finality in good network conditions, but in case >1/3 of the validators get nuked we can use Emmy+ to recover without hard-forking out the offline validators by doing an unsafe reset. The approach is somewhat similar to what Polkadot is using.
The first one is having each language deals with this independently. Basically, you can compose well within a language, but not with others.
The second is developing an ABI for Tezos.
The third is integrating in Michelson.
1 is not dealing with the problem.
Given Michelson types were kind-of meant for this, I think 3 is better, as 2 is the worse of both worlds: you have to standardize an ABI and conform to Michelson types.
For 3, the question becomes: “What should this standard interface contain?”, and I think it’s worth its own post.
Good to know! Would be great to share the benchmark data with the new storage upgrades. Even if there are time constraints 5k would be an acceptable reduction imo.
I think it would be tremendoulsy helpful to create issues of things that are currently annoying to you. Most of the core devs are very used to the software and have learnt to love and live with it’s quirks.
On the second point we will probably reach the point of diminishing returns in how much it helps decentralisation.
Any plans on implementing a messaging layer in the reference node for example like the matrix protocol to allow for off-chain communication? Currently the proposed tzip-10 standard and its implementation beacon uses its own matrix network and only has a couple of nodes. Ideally such a communication layer would be built into the Tezos node to immediately profit from a greater decentraliztaion.
Besides dApp to wallet communication other examples that could leverage such a messaging layer come to mind are multi-signature wallet coordination etc.
