by Dan Buchholz

Recently, we did a bit of refactoring across the Tableland development stack. We published a number of new versions for the following packages to reflect the latest changes:

• @tableland/sdk: v5.0.0 was released and includes some small but breaking changes due to D1 API conformance (only affects the exec method). It also adds some new polling functionality and introduces default polling times per chain, which resolves some problems users experienced on chains with long block times.

• @tableland/cli: v5.3.2 includes polling behavior fixes via the SDK release, so (similarly) chains with long block times won’t abort early.

• @tableland/local: v2.1.1 simply bumps the SDK dependency to the latest, in case you’re using it with other Tableland clients.

• @tableland/hardhat: v0.0.7 is rather simple in that it updates deps to help resolve potential conflicts if you’re also using any of the releases above in your Hardhat projects.

• @tableland/evm: v4.4.0 includes a new export for validator polling timeouts. This is used by the SDK for polling behavior but could be useful in other scenarios, in case you need to know how long a table might take to materialize on the validator after transaction finalization. E.g., chains like Polygon, Ethereum, and Filecoin wait 1 or more blocks before optimistically materializing a table whereas ETH L2s don’t have that restriction.

• @tableland/node-helpers: this is a new package, released as v0.0.2. It’s pretty simple in that it only implements a jsonFileAliases feature that, previously, was part of the SDK. It provides an export for table alias setup in a Node.js environment.

Also, a couple of notes on tooling updates:

• All starter templates have been updated accordingly to use the latest Tableland package versions.

• Lastly, the Studio has released various UX improvements based on user research as well as feedback from hackathons. These will continue to come iteratively.

by Avichal Pandey

We previously explored set-based cryptographic hashes in the context of homomorphic hashing. In this post, I want to illustrate implementing a hashing scheme with multi-set semantics in Go using the go-ristretto library.

Multisets are sets where elements can repeat. In our hashing scheme, an item's hash representation does not depend on the order of elements. Elliptic curve operations do all the heavy lifting for computing the hashes. The go-ristretto library provides a Go implementation of the - Ristretto group.

Ristretto is a technique to construct a prime-order group from a non-prime-order elliptic curve, providing safer and more efficient cryptographic operations.

// MultisetHash contains `accumulator`, // it is a pointer to a `ristretto.Point`. // This point serves as the cumulative hash // of all elements in the multiset at any time. // // Each item in the set is represented as // a `ristretto.Point` on the curve type MultisetHash struct { accumulator *ristretto.Point } func NewMultisetHash() *MultisetHash { var p ristretto.Point p.SetBase() return &MultisetHash{ accumulator: &p, } } // Insert implements a "set" insert, // using Elliptic Curve Addition. func (h *MultisetHash) Insert(p *ristretto.Point) { h.accumulator.Add(h.accumulator, p) } // Removes recomputes the hash of set with the // item removed. func (h *MultisetHash) Remove(p *ristretto.Point) { h.accumulator.Sub(h.accumulator, p) } // Similarly, you can implement other methods // relevant to sets // Here is an example of using the Insert hashSet := NewMultisetHash() // Create a new point for your data var point ristretto.Point point.DeriveDalek([]byte("foobarbaz")) // Insert into the set! hashSet.Insert(&point)

As shown, elements are inserted by adding their corresponding Ristretto points to the accumulator. They are removed by performing subtraction on elliptic curve points. Similarly, we can implement other set operations such as union, set-difference, etc.

The multi-set hashes are versatile. They can be used in several applications, such as ensuring the integrity of datasets where the order of data isn't fixed. They are also used as cryptographic accumulators in specific scenarios.

by Jim Kosem

When preparing to speak to a large room full of developers, as a designer you need to think a lot different. But this is exactly the problem with the approach many designers take with this sort of thing. We talk about empathising with users and collaboratively defining problems and shaping solutions, yet often forget that developers aren't just people building things for us, they're also users.

Just like someone using any sort of consumer application, be it to hire a car or get something delivered, if your user is a developer, you need to understand their inputs, outputs, concerns and frustrations. We as designers need to also realise that if we're helping build tools, that we need to loosen up with things, because we are helping design ranges of possible use. We are helping build ways of building things.

• The Rebuild Ownership 2.0: Internet Privacy hackathon has started an runs for about a month, until December 10. ICYMI—the Tableland team and other sponsors from the event participated in a Twitter/X space: here.

• If you’re building interesting technology and are looking for grant funding & support, check out the Tableland Pilot Program.

• We’re at Devconnect / LabWeek in Istanbul, starting today. Keep an eye out for us there or dive into our Discord if you’d like to connect.

Want to dive deeper, ask questions, or just nerd out with us? Jump into our Discord for weekly research office hours. Or, for hands-on technical support, you can join our weekly developer office hours.

And if you’d like to discuss any of these topics in more detail, comment on the issue over in GitHub by searching the date and finding the specific contributor who wrote the blurb!