Token protocols on BSV: Sensible Contract

Getting your Trinity Audio player ready...

In the next article of our series of interviews with token protocol founders on BSV, we interview Gu Lu, co-founder of SatoPlay and co-author of the Sensible Contract whitepaper, a proposed solution to solve “contract backward-tracing and collaboration” for BSV smart contracts and tokens.

What can the Sensible Contract protocol provide that no other token protocol can?

Gu Lu: Please let me clarify that Sensible Contract is not a token solution which competes with other ones (one use case of it does). It’s a contract model which provides on-chain back-tracing and collaborating for existing bitcoin scripts. By enabling these capabilities, we can implement a handy token/NFT system like BCP01 & BCP02 without any hassle. In BCP03 you can also find out how Sensible Contract simplifies the creation of an ordinary on-chain swap by formulating a collaborative global state in a graceful way.

Sensible Contract is not here to compete and try to outperform a given token system since day one. On the contrary, it could be used to make the given token system simpler and easier to write and maintain, if that system is written in sCrypt. It helps you on two aspects, specifically.

1. First, by hiding details of cumbersome legitimacy backwards tracing and validating, it helps you to focus on your business logic with your tokens or other assets you defined without worrying forged inputs from unknown parties.
2. Second, by providing a collaboration mechanism, you are able to access more business-relevant data fields which are not available in the current ordinary transaction context.

The collaboration feature opens a new and very expansive territory to explore. Contract communication could be quite useful to implement automated multi-phases function for non-trivial business logic. The collaboration mechanism consists of three levels:

1. Multiple inputs identifying each other within the same transaction (which is elaborated in the whitepaper)
2. Multiple modules in the same locking script; (this works in a “function dynamic folding/unfolding feature” enabled context, using state-jumping to minimize the runtime script size dynamically by folding those functions not being used and unfolding them as needed)
3. By propagating specific fields of the data segment inside the locking script body, a contract can collaborate asynchronously with another contract not in the same context.

As you may see, this provides many flexibilities from different dimensions which benefits a much larger spectrum of applications, and it goes far beyond the whitepaper which contains only the first level at that time. We are in a very active development cycle in this no-man’s territory to improve both the contract model itself and the applications it incubates.

The Sensible Whitepaper did a great job highlighting how all token protocols face the backwards tracing (aka Back to Genesis) problem – why it is so important token protocols to mitigate this?

Gu Lu: Before talking about the tracing problem, I would say the said Layer 2 solutions (by using an op-return based solution like Omni-layer used by USDT and using external service to validate transactions) shouldn’t have this issue at all in the first place because you can always ensure the legitimacy by improving the external off-chain service. But, by using that, you probably don’t need the bitcoin programmability at all, and it’s not “programmable money” anymore, it literally says “let’s create a markup system on cash and enforce the rules by interpreting the markups together.”

By utilizing Bitcoin script to ensure the on-chain legitimacy for your assets, backwards tracing is inherently an unavoidable issue if you want to solve the problem inside the boundary of bitcoin virtual machine. Because the value of satoshis comes from the node software. The system itself ensures that satoshi is such a thing that is not creatable, duplicatable, delete-able, etc. But all script-created resources don’t share that “first-class privilege,” there are thousands of ways of hacks to break into a token system by creating a not-easily-recognizable forged input, if you cannot trace backwards to its genesis in a very fast and effective way.

Frankly speaking, backwards-tracing patches the largest hole but not all of them. The programmer still needs to be careful not writing bad code to accidentally ruin the asset in an unexpected way in their code. This (the assets could be broken if the contract contains overlooked mistakes) is the same case in Ethereum’s solidity.

However, in modern environments like Cadence in Flow, this is a solved problem by utilizing the ‘resource-oriented’ paradigm. Assets created in those environments are well-defined “first class citizens” like the value of satoshis mentioned above and are impossible to be accidentally duplicated or deleted.

The details of backwards tracing could be found in this presentation:

Here you’ll find the pdf and the full content in Chinese (sorry but it may be auto-translated).

Are the advocates for Sensible Contract still asking for a protocol change to solve the backwards tracing issue?

Gu Lu: No.

After we knew the attitude of nChain we will no longer call for a node upgrade anymore as soon as we knew, because we want to put our efforts into building prototypes and products more effectively, not arguing and advocating repeatedly to be “accepted.” The most important thing is whether it helps the development of applications, with or without the so-called “protocol change” (which technically it isn’t).

Sensible Contract works well with 100% features it promised without upgrading PreImage. The next version of the whitepaper would be revised heavily with much more valuable pieces being added, and the ‘PreImage upgrading’ being moved into the footnote area of the implementation section to avoid unnecessary arguing.

Do you think the backwards tracing issue can be solved without a protocol change?

Gu Lu: It could be in the future.

People are still working on this actively and it’s too early to say it’s a dead-end.

Why is it a requirement to increase the Bitcoin script size of transactions to enable applications like TokenSwap to be able to launch?

Gu Lu: We want a bigger size limit for a single locking script so that we don’t have to selectively remove a lot of business code and functions to punch it through the 10KB gate. Just like we simply want bigger blocks than 1MB to have more transactions. It’s that simple.

We worked with TAAL and had 500KB running these recent months. It works well so we think it’s probably a good proposal candidate to ask node software maintainer to lift the limit to 500KB so that other miners can also mine these transactions in their blocks and we could get a generally shortened average confirmation time.

However, the size issue can be optimized, both on the toolchain side and application side. We are in an era that both toolchains and application contract code are not matured yet. In earlier days of Visual Studio, developers complained heavily about the executable size generated by Visual C++ on Windows platform using earlier versions of Visual Studio: “Why does a one-line ‘hello-world’ program generate such a huge executable (a 2-5MB .exe file)?”

Microsoft listened to them and optimized their compilers in later iterations. Just now I created a new project in Visual Studio 2017 minutes ago and made an experiment. The .exe size result is 47KB in Debug and 10KB in Release (both of them use default optimization options) It’s 10-100x smaller.

If you look at the generated bitcoin script of sCrypt output, you will realize that the same thing would/should happen. Xiaohui also confirmed that it has plenty of room to optimize toward a much more compact compilation but it’s generally low-prioritized because the scripted transaction is still uncommon nowadays. So we’ll work together to have a generally smaller locking script to make scripted transactions more compact in future iterations.

What are you most excited to see be built atop Sensible Contract?

Gu Lu: SatoPlay NFTex (NFT exchange), SensibleSwap (previously known as TokenSwap), SensibleScan (Asset Browser like Etherscan). We don’t see them being built, we put ourselves into building them with their developers. These are the three projects close to launch, and we know there are more projects in development. 

We are actively testing against the interoperability that the assets and tokens can be transferred across these products smoothly. This will be the most exciting features in the very near future.

Sensible is relatively lesser known within the BSV space due to its recent release and origination in the Chinese market. How do you plan to gain more overall adoption of the protocol?

Gu Lu: We generally don’t do too much to gain the attention because we have limited time and resources. We have to put them into the most critical parts of our research and engineering to push things forward, to try and fail quickly, to experiment with many possibilities so that we have generally more progress in a given timeframe.

People who know well-enough about Bitcoin script will find us somehow and they are generally willing to have great conversations with us. That would be much more productive for all of us.

Token protocols

Can you give your thoughts on the ‘Layer’ labels for Tokens? (ex. STAS as L0, sCrypt as L1 and Tokenized as L2)?

Gu Lu: We heard different “layering” approaches. I don’t plan to compare them in detail like I did using a diagram from L2 to L1 in earlier talks in February. Because no matter how the token system is implemented, it’s ok.

Each of them deserves a chance to be used by others. It’s whether the system is continuously widely used that matters. It’s not about whether your design is clean and elegant, it’s about whether you are going to put far more dirty work into it in the future, to have more and more projects believing that your solution is a strong cornerstone that is reliable and stable and will be well maintained and iterated in the foreseeable future.

What are your thoughts on using satoshis for tokens?

Gu Lu: By doing this, satoshis are “sliced/staked/burnt” into tokens which could be recovered as needed (or not).

It’s viable, but very hard (if not impossible) to do rich contracted financing features that could generally be found on other chains. So yes, probably in some use cases that would be good enough to have a simple satoshi-based token.

Do you think multiple Token protocols atop BSV can exist? If so, why? How is that different than claiming multiple crypto currencies can co-exist?

Gu Lu: Frankly I don’t know. I don’t generally over-simplify things, especially when it comes to such a globally evolving complex system. It could take much longer time than most bitcoiners think to have “one chain to rule them all.”

Engineers introduce various concepts and methods to deal with different situations and make different trade-offs among many aspects, using different token protocols (or maybe even combined in some cases) to form different solutions, just like they use different programming languages, frameworks, libraries to express their idea effectively.

Ignoring the complexity and the diversity and forcing people to unify ‘something’ may not be a good idea. 

I’d rather encourage a more inclusive atmosphere that enables people to express their ideas and show their talents without worrying that being isolated.

Ethereum

How can BSV out-compete Ethereum?

Gu Lu: This is a huge question, and I haven’t been prepared to answer it yet. Generally, BSV has potential to contain much more transactions in orders of magnitude than ETH. But can all applications running on EVM be migrated to run well enough on bitcoin VM?

That’s not clear and obvious. Solidity and the account and event model surely isn’t sophisticated well enough but they do bring value that cannot be easily replaced by UTXO-based contracted applications. However, we know too little about bitcoin and we are still learning, I hope I can be more confident next time I’m asked this question.

How can BSV profit from cooperating with ETH and DeFi?

Gu Lu: ETH/Defi gives us excellent use-cases to explore what we can do with Sensible Contract. We’ll do more research and gain more experiences by analyzing what happens in these projects (what went right and what went wrong) After we built a prototype on BSV which runs a similar business logic, we can use ETH as a benchmark for our apps. How the fee compares, how transaction throughput compares, etc., that generally saves a lot of time.

General

What impact do you think the LAW narrative has had on BSV with respect to tokenization?

Gu Lu: The political correctness answer to this is “code is code” and “law is law”. But using blockchain itself to perform automatic and immediate validation doesn’t disable “the law” from functioning. You can still use “the law” to defend yourself when it’s needed, just like any scenario you’ll meet in life. By using contract correctly and wisely, you lose nothing (in aspect of “the law”) but gain automated validated transaction efficiently. That’s why we use bitcoin script in the first place.

If you are referring to using op-return to mimic a ledger, and using an authority or external validators or such (and rely on “the law” to catch them), you will probably have a significant higher cost than your opponent, who use the automated contracted method approach.

Yes, you can fall back to the traditional ways of doing things and keep telling people that “the law” would help. But the point is, “the law” would/should always help, regardless of how you do your business. If the law helps anyway, why not choose the cost-effective method using contracted model automated that gets executed and validated on-chain?

Having that said, I think it’s worth it to mention that a well-formed KYC and AML process is very valuable to people who want to build their business on BSV seriously. We are also very active working in this area.

If you could wave a magic wand and change something about the BSV culture or business environment, what would it be?

Gu Lu: I’ve been a veteran in game industry for 15 years. I learnt that the culture and the environment of a given sector consists of many aspects which affect each other in a very complicated way, which is worth respecting. It’s wise to adapt yourself to it in different ways and see if you can contribute in an effective manner or not.

Additionally, I tend to think in such a way that utilizing the attributes that BSV can afford uniquely to build something good for my purpose, not build something that the BSV ecosystem ‘consider’/ ‘accept’ that it’s worth doing. I force myself to always think from such an “external view angle” to the community. Because the world doesn’t/shouldn’t ‘carefully’ help BSV to grow and succeed. On the contrary, BSV should survive and provide value to other industries (which in my case, the game industry) to legitimatize its existence.

Thanks for reading this.

I’ve attached a Sensible Contract ecosystem diagram here for your reference below.

Thank you, Gu, for taking the time to answer my questions. I hope the readers learned more about Sensible Contract. Please be on the lookout for the next interview in this series.

This article was lightly edited for grammatical and clarity purposes.