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.
Q: We keep seeing issues with P2P in the node that ultimately is making us lose endorsements and baking slots. Any tip on what can a baker do to increase stability?
Dune just released a feature that allows a baker to “lock” the maximum number of rolls they want to be given by the network. This allows bakers to protect themselves against over-delegtaion and gives them the ability to have a bit of liquidity. Do you see a similar feature coming to Tezos? What are the pro/cons of such a solution for protecting against over-delegation?
The latest mainnet branch (released today) fixes a bug in the mempool which caused some endorsements to be missed. More precisely, if endorsements arrived too soon (before the endorsed block was validated), the mempool would reject it. This particular problem should resolve as more and more node upgrade. In the meantime, you can try to play with the endorsement delay parameter to try and make your endorsements arrive a bit later, but of course this is risky as if it arrives too late, you’ll make it worse.
