by Joe Wagner

This week we are getting ready to launch an early tester version of the Tableland Studio at https://studio.tableland.xyz. The Studio is the official tool to help you to easily build applications with Tableland. I won't go into detail on all the features of Studio here, we will have entire post on that. Of note, however, is that we have been using Vercel to deploy Studio during early development. This week, as we stress tested Studio, we found an interesting issue with deploying our API on Vercel.

The Studio is built to help folks use Tableland for production level applications, but the Studio itself is also built using Tableland. This means the internal database that Studio uses to manage accounts, teams, projects, and so on, is…you guessed it, Tableland! These internal tables are owned and managed by the Tableland team. The Studio has an API that authenticates users and then handles requests to create and update account specific info. When one of these requests comes in, the api uses the Tableland SDK to write to our internal tables.

While testing with one or two developers everything was working, but when we started hammering on the app with a large number of accounts and requests we started getting nonce_expired errors. We had configured the SDK with a nonce manager, and not really thought too much about the implications of how Vercel scales applications.

Under the hood, Vercel uses serverless functions, the benefits of this are well known. However, the drawback to this is that the each instance of our API needs its own wallet configured with the correct Tableland ACL rules. In order to have a unique wallet per process the Studio API needs to have the wallet info in the env of the process. Looking backward, this almost seems obvious but we had been focussed on getting the product out the door and Vercel seemed to "just work."

After some debugging and digging into Vercel docs, we didn't find an easy way to reconfigure how Vercel was deploying Studio. Our co-founder, Sander, had mentioned that he recently had a good experience trying out Railway. This seemed like a great opportunity to test Railway a bit more rigorously.

Sparing the details of our specific configuration, in less than 45 minutes we had fully switched to Railway. The setup and config made it simple to enable a per process env that solved the nonce_expired issue without any code changes.

“Every act of creation is first of all an act of destruction” ~P.P.

Switching to Railway worked like a charm and the team is generally exited about using Railway more, however being able to easily use serverless functions without these kind of nonce issues would be nice.

This problem has spurred some internal research into the state of the art for decentralized nonce management. No promises, but the Tableland team is hoping to, at least, come up with a longer post about this topic. Or potentially even release an open source tool to solve this using decentralized best practices.

by Carson Farmer

Every now and then, I go back to the (poorly named) concept of hyperstructures: “crypto protocols that can run for free and forever, without maintenance, interruption or intermediaries.” These so-called structures take the form of protocols that run on blockchains. Something can be considered a hyperstructure if it is: unstoppable, free, valuable, expansive, permissionless, positive sum, and credible neutral.

As defined, hyperstructures seem like impossible things. How can it be both free and valuable? I think maybe if you time-bound some of these requirements, they start to seem a little more realistic. For instance, what if something was free over the long term? Or free under certain conditions?

This seemed like an interesting thread to pull, and while @Andrew Hill and I were chatting about two-sided utility markets and exploring ways of incentivizing both the supply-side and demand-side together, we started to unravel it a bit…

Firstly, there are a number of ways that other projects have tried to incentivize supply-side (e.g. validators) and demand-size (e.g. users) as separate groups, or together. This is particularly important in the early days of a network. In the past, lots of projects have used approaches that required “off-chain” human in the loop mechanisms to achieve this (like airdrops, KYC steps, etc). So as part of our exploration of Filecoin’s hierarchical IPC subnet protocol, we wondered if there were any new opportunities to handle this in a unique and interesting way.

Normal staking is all about supply-side rewards, which are the dominant mechanism for creating incentives for validators/service providers to do work on a network. However, we might also want to include a novel demand-side incentive/rewards mechanism in order to incentivize:

• “signaling” to the network that demand is real, ready, and looking for supply,

• “curating” network quality by identifying and staking into high-quality subnets,

• “demand” by allowing liquid staking, thereby reducing opportunity costs for holders, and

• “participation” by providing a mechanism for cheaper transactions in exchange for longer-term staking within a given subnet

Borrowing concepts from liquid staking, Solana’s “set it and forget it” concept, and “key money” or more specifically “jeonsei” from the South Korean rental market, we proposed a type of liquid staking process where users who deposit funds into a subnet are effectively providing “key money” to the subnet. These funds are essentially a “signal” to the network that they intend to use this subnet, with usage roughly equivalent to size of deposit plus some interest.

Jeonsei (or jeonse), meaning "money in full" and often called "key money", is a unique Korean system. Tenants provide a large upfront deposit, usually between 25% and 80% of the property's value, instead of paying monthly rent. They only cover utilities. At the end of the tenancy, the full deposit is returned without interest.

Some portion/percentage of the deposit is “locked” for a period of time, and is slowly unlocked at each block step. After a certain period, the entire deposit can be withdrawn. In the mean time, the deposit is essentially acting like a delegated-stake (hence liquid stake) within the subnet.

Each block the depositor (user) earns some cut of the reward (as in normal protocol staking), with a specific tweak: the earned rewards must remain within the subnet (or project, protocol, etc). The depositor (user) can spend these earned funds on transactions (or features, utility, etc) within the subnet, effectively leading to near “free” usage over longer periods of time.

Of course, you have to design your staking rewards and transaction fees accordingly so that you incentive the right time-bounded participation levels for your specific protocol.

Elaborating a bit on that tweak: unlike standard staking in other protocols, users/stakers who earn interest/rewards, cannot withdraw any interest/rewards earned from the subnet. Like in a jeonsei market, they may withdraw up to their principal deposit once it has been fully unlocked (this is similar to the rental period in a jeonsei market). As pointed out by our colleague @Sander Pick, in practice this might require the use of colored tokens or other ways to represent tokens limited to a subnet.

We might also want to consider allowing depositors to drawn down their deposit to some specific percentage below their initial principal, to effectively subsidize early usage. However, we would then require them to keep their coins “locked” in the subnet until they have effectively “paid off” their usage from collected interest over time.

The locked deposits act like a signaling mechanism to the network, similar to something like the Graph’s signalers. This incentivizes the supply side to spin up service (e.g. compute, storage, output, etc) relative to the size of the deposit. This also incentivizes depositors to deposit the right amount of funds into the subnet to cover their anticipated costs. They can draw up and down their overall deposit over time, eventually optimizing their “stake” to get to near costless transactions (or features, utility, etc) over very long periods of time, and more costly over the short term.

This describes the ultimate pay as you go model, with built-in scaling. If a user comes in with serious demand, they have a mechanism to signal to the network they need resources. The network has a mechanism to ensure those resources are well spent, and not just a flash in the pan grab for one-off compute (or resources, etc). It also provides a way for users to potentially get really cheap services while maintaining their initial investment. Aaaand, it also helps with security on the network (”staking”) while maintaining liquidity and actual utility of the deposited tokens (”key money”).

So I’m calling this something like Jeonse staking, but I’m guessing something like this already exists… so what is this called? Do other networks have similar concepts? Will it work? What do you think?

by Dan Buchholz

The Open Data Hack is over, with a final event coming on Oct. 12th where we'll announce the official winners of our 1st/2nd/3rd place and pool prizes. In total, there were 20 projects that built on Tableland!

Open data was the general theme for the hack, and Tableland's chain-driven data storage and access control made it a perfect fit for many developers. There were a number of Data DAOs that used smart contracts to create datasets and provision how users could collaboratively write data to a shared index with some onchain rule (e.g., gating with NFT ownership). Another interesting projects included porting EAS—onchain attestation for Ethereum—to the Filecoin network and using Tableland to manage permissionless attestations as a public good. There was even a project that built a marketplace framework for 3D printing objects in a localized area!

All in all, there were so many interesting projects that made it tough to judge winners. Now, we're kicking off the ETHOnline hackathon with the launch of the Tableland Studio web application! Prizes are focused on the Studio, along with our (experimental) release of Tableland Basin for continuous data publishing from Postgres to web3 storage.

• The Mission Board—our community board for open contributions—has seen activity, but we're still looking for our first completed mission. Take a look at what's available and give one a try: here. We did have some “off-board” missions for those who gave us feedback on our Studio app. We awarded 500,000 FT (Flight Time for Rigs) points to a few folks for their time and effort helping us make the Studio product as great as it can be!

Want to dive deeper, ask questions, or just nerd out with us? Jump into our 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!