Jakarta 2.0

Jul 14, 2022 | DeFi Updates, Tezos

Announcing “Jakarta 2”

Changes in Jakarta 2

The changes in Jakarta 2 with regard to the previous Jakarta proposal concern only fixing the reported bugs. In this section we shed more light into these issues, and detail how they were corrected for the new protocol proposal.

Bugfix for uncraftable rejection operations

The first bug concerns rejection operations, that is the Layer 1 operation which allows a honest node to refute an erroneous or malicious commitment in a TORU. A flaw in its implementation ultimately made it possible for an attacker to publish commitments whose refutation proofs would not fit within the maximal allowed size for Tezos’ manager1 operations batches — 32 KiB.
This limit underpins a design decision in the current implementation of TORUs: there is an upper-bound on the number of Layer 2 transaction batches from the same rollup which can be (ahem!) rolled up within a given Tezos Layer 1 block. For each of these batches, operators of the client rollup are required to include the batch’s hash in their respective commitment operation on Layer 1. Inserting too many batches from the same rollup in the same block would make it impossible to insert a valid commitment for it in a subsequent block, which would result in the incriminated rollup being stuck forever.
Rejection operations denounce a specific rollup commitment, which contains one hash per batch of Layer 2 transactions. Honest rollup accusers can trivially find the first hash that they disagree with, and craft a rejection operation to refute said batch. The rejection operations requires two key pieces of data: (1) the target batch itself, and (2) a collection of Merkle proofs which allow to replay said message. This raises an immediate concern. What if the provided Merkle proofs are just too large to fit within the size boundaries a Tezos Layer 1 manager operation? If the batch is large enough (that is, it contains enough transactions), this can definitely happen.
To tackle this risk, TORUs relies on two design choices. First, TORUs encode Merkle proofs using a format that allows to send truncated proofs. Second, a batch for which one can exhibit a valid, “large enough” truncated proof has to be considered a no-op.
In the first Jakarta proposal, the size boundary for Layer 2 operations batches was 5 KB, and a truncated proof larger than 30 KB was required, in order to prove that a batch should be considered a no-op. So, in order for an honest rollup node to prove that a batch of size 5KB was to be ignored, it needed to produce a refutation whose size was at least 35 KB (~36 KiB)… which does not fit within the 32 KiB limit on Layer 1.
The fix is straightforward: accept a truncated proof of 30KiB – sizeof(batch). In this way, rejection operations are guaranteed to fit within a single Tezos manager operation. The curious reader can have a look at the diff of the MR implementing this bugfix.

Bugfix for forged zero-valued Tickets

The second bug concerns Tezos Tickets. The latter are an abstract representation of tokenized assets, and in TORUs, they are used to represent the assets deposited and transacted within the rollup.
Tickets can be seen as a tuple consisting of: (1) its (typed) payload, (2) the address of the smart contract which has minted it — a.k.a its ticketer — , and (3) a quantity. A ticket can be split into two (and eventually more parts), assuming that the total sum of the quantities associated to each of the two resulting half-tickets is equal to the amount of the original one. Dually, two tickets with the same payload and issued by the same ticketer, can also be joined, adding up the quantities.
stakerDAO-logo-white
https://serokell.io

Serokell is a software research and development company, focused on high complexity tasks in the area of computer science.
Our team is composed of developers, designers, engineers, computer scientists, and mathematicians, all to help you realize your vision.
We use functional programming to write robust code that works anywhere, anytime.

Initially, we worked with StakerDAO to implement the STKR governance token a monitoring app on Tezos. After that, we moved to BLND token and implemented a set of Ethereum contracts for holding BLND and performing buyback with them.

We also implemented a web app to run the buyback process.

After that, we designed and implemented the Bridge application and associated set of contracts that allow exchanging BLND and wXTZ tokens between Ethereum and Tezos.
We are working on Bridge backend support for ALgorand now.

Social links:
Twitter
Telegram
YouTube


Projects

BLNDSTKRStakerBridge

Skills

Contract development (Ethereum, Tezos)
Web application development
Development of applications interacting with Tezos, Ethereum and Algorand blockchains.

This will close in 0 seconds

randlabs-logo
https://randlabs.io/

Rand Labs is a blockchain development lab specialized in Algorand technology.

At Rand Labs we have developed specialized expertise in blockchain technology. Through 8 years of experience, we have worked closely with all major blockchain protocols and have garnered valuable experience in the industry that helps us deliver the maximum quality in our products and those of our partners.

We spend years training and advancing our team members' skills by facing ever more complex technical challenges in the blockchain space. Having helped and participated in the development of many of the most popular blockchain products in the world since 2013, we are in the capacity to deliver quality solutions regardless of the difficulty of the problem.

Despite having built numerous blockchain products and consensus upgrades from scratch, we believe a business-oriented acumen is as important in delivering maximum product-market fit. With our long history in the industry, we have developed a valuable network of relationships that is available to our partners. Additionally, The Rand Labs management team has been very active as investors and advisors in the space. We have invested in and advised very successful projects. As important, we have seen many projects fail which allowed us to learn valuable insights from those failures.

Social links:
Twitter
Github
LinkedIn


Projects

wALGOStakerBridge

Skills

Product DevelopmentAlgorand Smart Contract development and auditsBackend developmentInfrastructureDev ops UX UI

Fun Facts

Rand Labs has always been a fully remote company, way before the impacts created by COVID. We believe this has allowed our company to operate completely crypto native, including payroll, corporate structure, and revenue. We feel that by operating this way, every individual in our team is positioned to deliver the best products and solutions of this industry.

This will close in 0 seconds

stove-labs-logo-103
https://stove-labs.com/

Learn more on Stove Labs Github, Twitter, and Telegram.

Projects

wXTZStaker Farms

Skills

Tezos BlockchainIPFSReasonMLSmart ContractsOpensourceDAPPsTutorials

This will close in 0 seconds

staker-services-ltd-logo-667
https://www.staker.services/

Staker Services provides technical, business and operation services for the cross-chain era. The Operations team specialised in the DeFi ecosystem, with experience in launching products across chains - from Ethereum to Tezos, Algorand, Polkadot and more.

Projects

BLNDwXTZWALGOSTKRStakerBridge

Skills

DevBusiness DevelopmentProductMarketingLegalFinanceOperations

This will close in 0 seconds

chainsafe-logo-104
https://chainsafe.io/

"ChainSafe Systems is a blockchain research & development firm with a focus on building infrastructure for Web3. We are actively contributing to the Ethereum, Ethereum Classic, Cosmos, Polkadot, and Filecoin ecosystems and are open to contributing to other Web3 ecosystems where we see merit. Feel free to visit our website or email [email protected] with any inquiries.”

Projects

PINT

Skills

Blockchain InfrastructureResearch & DevelopmentSmart Contract Audits

Fun Facts

Team members in 17 countries and counting!

Video

This will close in 0 seconds

Subscribe for Email Updates

Name

This will close in 0 seconds