Tezos Core Development AMA -- Nomadic Labs, Cryptium Labs, DaiLambda

Tezos Agora will be hosting its first AMA with development teams that work on the core protocol.

Our first participants for this AMA will include Nomadic Labs, Cryptium Labs, DaiLambda, and more!

AMA time/date: February 13th, 18:00-20:00 CET

19 Likes

Tezos Core Development AMA is now open to questions for community members that will be unavailable during the focused session. Join us later this evening from 18:00 - 20:00 CET for the live event.

4 Likes

What’re the current areas in Tezos where research and more work is required? Are we already there where Tezos could support any kind of complex smart contracts as compared to other blockchains (i.e. ethereum)

1 Like

Which functionalities from other blockchain would you like to see implemented on Tezos? Follow ups on that question: Which one are you working on? And which one would you like to see developed by different teams?

2 Likes
  • When can we expect simple baker controls like the ability to turn on/off accepting delegations? Other chains have this extremely SIMPLE ability. Tezos has been out for over a year and bakers still must deal with overdelegations. The ability to turn on/off would drastically help in this area. There are still other issues with overdelegation, but this is #1.
  • What are the thoughts of being able to direct baking rewards to different addresses? If the protocol could send rewards to a KT1, for example, under the baker’s control, then bakers could implement smart-contract-based payouts systems.
  • The current “garbage collection” done for full nodes removes context data older than 5 cycles. This makes it impossible for bakers to collect information about rewards/payouts of their delegators. Is there a possibility of changing the garbage collection to be less aggressive?
1 Like

When is Zk-Snark coming to Tezos? Next proposal?
Have you news about Layer 2?

2 Likes

There is no immediate plan for now to have a generic zk proving scheme in Tezos, although we’d like to have one in the future. We do plan to propose privacy-preserving transactions in 007, which are implemented using the Sapling protocol from ZCash and in particular the library developed by the ECC. Sapling does use zk-snarks internally, but they are very specific to privacy preserving transactions.
More info https://blog.nomadic-labs.com/sapling-integration-in-tezos-tech-preview.html

5 Likes

I think there are a number of things that could be useful for Tezos. Generally speaking technical evolution will be a constant requirement, specifically with regards to base layer protocols. In the next years I expect this space to evolve rapidly and Tezos should try to not lose the race.

I think very tangible examples of things that are needed:

  • finality gadgets ala Polkadot (not yet, but I’d like to)
  • more execution environments in order to have WASM VMs (not yet)
  • better key management for validators, like enhanced baking accounts (currently working on it)
  • more advanced cryptography, like BLS signatures for signature aggregation (in the pipeline)
  • token bridges over IBC to other chains (probably towards the end of the year, depends on the pace of IBC)
  • some form of sharding (not yet, but I’d like to)
  • multi-asset shielded pool (currently working on it)
  • new OPCodes for Michelson (currently working on it)

This is just a short excerpt and it’s likely that this list will dynamically change based on inputs from the community as well as novel research conducted by us and the wider industry. However in the end it’s always up to the community to decide what they want to vote into the protocol.

5 Likes

Layer two is one of the major focuses of LabNet. Currently there are plans to implement both optimistic and zk rollup.

2 Likes

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.

About the last point, I have two answers.

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.

1 Like

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?

2 Likes

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.

1 Like

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.

1 Like

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.

2 Likes

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.

2 Likes
  • 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?

2 Likes