Summary of Hoskinson DApps and Development talk, 2022-01-02

Full video is here: [Whiteboard: DApps and Development – YouTube](

New year: Fun, lots will happen, lots to build and do. IOG will be building a new studio, and more education will be happening. This talk is a whiteboard session. [This summary does not include Hoskinson’s drawings, but rather just the gist of his talk.]

To learn about the Cardano development experience, start with For a deeper intro comparing the Ethereum programming model with the Cardano (extended) unspent transaction output (eUTxO) model, see: [[2003.14271] UTxO- vs account-based smart contract blockchain programming paradigms (]( EUTxO lends itself to more of a functional, as opposed to imperative, programming style.

At this point, Hoskinson moved into the meat of his talk, beginning with a discussion of expressiveness. At one end, the minimal end, of the expressiveness scale is Bitcoin Script (based on UTxO). At the other end are full run-time environments like the Java Virtual Machine (JVM) that can run entire applications, like Minecraft. In the middle, but more towards the JVM end, is the Ethereum Virtual Machine (EVM), which possesses great expressiveness and power but needs (for security and other reasons) to be restricted in various ways.

But is a model as expressive as Ethereum’s needed for things like NTFs, oracles, smart contracts, and DeFi? Or will something less expressive (in which it is easier to scale, verify, predict costs, and secure), work as well?

In contrast to the Ethereum model, the Cardano eUTxO model starts with something leaner, more towards the Bitcoin Script end of the expressiveness scale. At that end of the scale, it is easier to be sure things like smart contracts do what they purport to do without unexpected side effects. Cardano starts with this more restrictive model and dials it forward as needed via mechanisms like Cardano Improvement Proposals (CIPs), rather than the reverse, that is, to start out very expressive and powerful, but then dial back and limit that power as problems turn up. The same is also true about centralization (it is better to start out *de*centralized then move towards more centralization, e.g., on sidechains, than to try to retrofit a centralized system for decentralization).

Cardano is very concerned with things like predictability, e.g., with how much a transaction will cost (*deterministic cost,* virtually unattainable in account-based models). Speed is another issue, and it is being gradually ramped up in a number of ways, for example, through block-size increases and through both network and core-node optimization. All this work happens within the limits of a propagation goal (or limit), namely that new blocks added to the chain must reach 95% of nodes within five seconds.

Because blocks are not created continuously, but at specific intervals, like a heartbeat, another way to optimize is to do work between these heartbeats (“pipelining”). One can, for example, create multiple blocks in parallel, between the heartbeats, then merge them in (part of the Ouroboros consensus protocol design). All chains are thinking about these same kinds of optimizations, and they operate under the same basic constraints. These constraints are network propagation speed and optimism (balancing trust and increased size and velocity against the need to stop and validate the extra blocks). On the Cardano blockchain, this involves *input endorsers,* which are being worked on*.* Parallel block creation, if you can achieve it, is a kind of blockchain “holy grail.”

All this optimization work is ongoing. The scientific design is in place, and the relevant papers and specifications are mostly done. It’s now more of an engineering and coding problem.

Hoskinson spoke of three additional, specific optimizations. The first is Hydra, i.e., using separate payment state channels. The goal is to have some version of Hydra running on the Cardano main network (mainnet) this year. A lot of smart contract and microtransaction work can be done in these channels. The second additional optimization is off-chain computing, where a result is returned to the main chain in a way that allows proof that the off-chain computation was done correctly. This method requires identifying trusted parties, and maps well both to the delegated SPO model, and to the eUTxO model. Finally, optimization can be done via sidechains (an “endless river,” as Hoskinson called it). Ouroboros builds a strong root of trust, and once you have that you can pick a subset of SPOs engaged in consensus and use that subset to bootstrap separate side chains optimized for speed. Each sidechain is centralized, permissioned (i.e., not just anyone can join), and potentially very fast, but backed and verified by the strong root of trust provided by the main decentralized, permissionless chain.

Speaking more generally, Hoskinson noted that microsummits are being planned to bring people together working in various areas, like DeFi. New CIPs will come (there are three already, like one for read-only eUTxO). DeFi Alliance will also be meeting. Developer Discord has over 11,000 members. Heavy investments will continue to be made in the Cardano ecosystem. Hoskinson believes in a multi-model world in which there can be a mix of imperative and functional programming, and he understands that the latter (functional, in the eUTxO context) is new and therefore hard. But he is committed to providing developers with tools, tutorials, SDKs, video content, and communities they will need. Over the longer term, in terms of cost, security, throughput, and predictability, the Cardano model will prove cheaper than the Ethereum, and other account-based, models. Hoskinson threw a number of barbs at Bitcoin and other maximalists, asking for collaboration. And he offered a number of pleas for developer patience and recognition of the cold, hard truths about the right way to develop decentralized, secure blockchain models.

Fonte: Reddit Autor rlgoerPost Original

Comments (No)

Leave a Reply