Tezos Core Development

‍

The goals of these features are, first, to give more flexibility for developers in the way they design their contract. Second, it is to make it easier to contribute to the protocol and to ensure its security.

‍
Here are the main features regarding Improvements:

- Deny zero ticket: tickets have been around for a while, but tickets of zero amount has become nuisance for upcoming SCORUs. To ensure security we proposed to disallow tickets of zero amount in order to ensure ticket semantic sane.
- Ticket balance transparency: Provide more transparency for indexers regarding ticket ownership. This would enable Tezos users to query ticket balance information for their accounts/rollups via indexers. Including 'Add ticket balance updates to receipts for transactions between contracts'.
- Contract event: we introduced a new capability in Tezos smart contract to transmit events with types for consumption by off-chain applications. It is economic to construct and transmit events which live in transaction receipts in blocks.
- Views: Views give the possibility to smart-contracts to interact with each other following a simpler common pattern and making interactions safer. That increases the flexibility of contract design, giving developers more choices to develop their own contract.
- Cache: Cache helps to solve the problem of speed storage at the protocol level, by splitting the data between “hot” storage (usually the RAM) and “cold” storage (usually a hard-disk). It gives faster access, and at a lower gas cost, to the data that is accessed regularly. As a result, it increases the overall throughput of Tezos, also called “the number of TPS (transactions per second)”.
- Global table of Constants: The Global Table of Constants is a proposed feature whereby smart contract developers can register Michelson expressions as “constants” and reference them in their contracts. This allows them to create larger and more complex contracts than they would be able to otherwise.
- Baking account: developed to increase the security of Tezos accounts, the goal of baking accounts is to allow users to register public keys as master key and spending key, in a key rotation process, and thus control the permission of their account.

‍

Here are the upcoming improvements:
- Implicit account tickets: to enable the capability of implicit accounts to own tickets, we now allow tickets to be transfer between any two of implicit accounts and originated accounts.
- Ticket balance receipt enhancement: following our work from Ticket balance transparency in Lima, the ticket balance updates for all possible cases of ticket transfer are now also shown up on the operation receipt.
- RPCs for Ticket balance: To improve the whole UX of ticket, we added two RPC endpoints to allow uses to query the balance of tickets for a given account.

‍

Maintenance is divided in two categories:
- Benchmark: Benchmark consists of executing code bits in different conditions and in a repeated manner to make sure that no performance regression, such as bugs or slowdowns, occurs. Moreover, among a great diversity of benchmarking activities, it prioritizes and focuses on main performance improvement directions. For instance, we are developing “Tezos Specification” (TZS Specification) format and benchmarking system for Tezos. It is a way of writing data that is both human and machine readable.
- Testing framework: the testing framework relies on automatic tests sequenced to check that every part of the framework works correctly. It tends to increase the speed of the protocol’s test and to improve the expressiveness of the tests, by multi-testing the protocol, even its most specific characteristics.
‍

Please find related blog posts about these topics:

- Introducing Global Constants

- Introducing Tezos Cache

- Communicating about the view issue in Hangzhou

- Announcing Hangzhou2