- 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.
We can see three ways to deal with the situation:
- 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.
I think you are thinking about Near. Near is doing sharding and Solana is doing massive optimisations.
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.
Hi team! Thanks for this AMA:
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?
I think it’s possible that the first real money invoice may happen in 2020.
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.
- → TQ Tezos and LIGO have also people working on protocol development
- → Do you mean with an invoice? It happened already with the Brest proposal a few months ago (which didn’t get voted in).
I answered this in a thread above:
Is it possible to begin price discovery on proposal invoices if development is currently being subsidized by Tezos Foundation grants? Seems to defeat the purpose.
I’ve read today the “Enhancing Baking Accounts” post from Awa. Will these options be already included in the next proposal and if so will both be up for bakers’ votes?
These options will most likely be available in 007. It will be up to the community to decide which option they want to choose.
We need to be very cautious with transferring extra data over the peer-to-peer network, but there could be exceptions for specific purposes.
I am not sure about this specific use-case.
One thing we discussed is a way to transmit snapshots or receipts over the network since their integrity can be checked.