Parsec Frontiers: We Took Up The Runes
Today we’d like to introduce the visual scripting solution for the smart contracts we’re working on for Parsec Frontiers. But before that, I’d like to talk about why we feel it is important, and in order to explain this feeling of importance, I have to start with things that are not directly related to the game, but are rather keynotes of the industry in general. If you don’t like starting from afar, please feel free to skip right to the Introducing Visual Smart Contracts section.
What do you do for a living Dad?
- In this scene, act three, scene one. Does Hamlet know that Claudius and Polonius are spying on him?
- I don’t know.
- You have to know. If Hamlet is aware of their presence, then when you speak these particularly famous words, you’re performing for the guy who killed your father and for the meddling old fool, both of whom are hidden in this room. But if you don’t know they’re here, then your audience is you and those people on the seats. But you have to decide.
Slings and Arrows¹, season 1, episode 5
The dialog above shows the example of a superobjective. We know this concept as something originating on stage, or behind the stage, but we may also apply it to a much more general question of who we are and why we do what we do.
In his famous insightful and inspiring talk “Inventing on Principle”², Bret Victor explains the importance of identity and responsibility of technologists, engineers, and developers. His own superobjective is the principle of immediate connection in computer tools. If you have not seen this talk, I encourage you to find an hour of your time to watch the magic of liberated ideas — whether you use computer tools to perform any kind of creative activity, or especially if you design and develop them. This lecture had a great impact on us in Artplant, and is implicitly responsible for what we’re trying to achieve with visual smart contracts.
Another example of identity would be the following fragment from “The Real Book of Frank Zappa”³:
What Do You Do for a Living Dad?
If any of my kids ever asked me that question, the answer would have to be: “What I do is composition.” I just happen to use material other than notes for the pieces.
Composition is a process of organization, very much like architecture. As long as you can conceptualize what that organizational process is, you can be a ‘composer’ — in any medium you want.
You can be a ‘video composer,’ a ‘film composer,’ a ‘choreography composer,’ a ‘social engineering composer’ — whatever. Just give me some stuff, and I’ll organize it for you. That’s what I do.
I wonder how many of us, with very different applications of our skills, can call ourselves composers after reading this. Probably quite a lot. What we do as developers is fighting complexity, and one of our two mighty weapons is (de)composition (and the second is, of course, proper tools) — we build complex systems from simpler blocks. Let’s keep it in mind when we get back to contracts.
Identity and responsibility are directly connected — identity is the superobjective we’ve got as engineers, the very personal and subjective understanding of what is right and what is wrong, and it’s our responsibility to bring the right to life, and eliminate the wrong. This mindset stays behind the most innovative technologies of the past, present and future. Bitcoin and Ethereum would never appear without the authors’ belief in the necessity of decentralized trustless payment systems and environments for financial applications — and the responsibility to bring those ideas to life.
When I think of my personal engineering superobjective, I can’t find a strict answer. I am fascinated with programming tools (in a very broad understanding of the term), and in particular how the same intent may be described in a large variety of languages, backed by very different concepts and media. In fantasy games and literature, you can cast spells by pronouncing abracadabra, making passes with your hands, or even whistling and playing musical instruments. Even combining the runes into spatial patterns. The programs are the magic of our time, but we are very limited in the means by which we can use to them to describe our intent to a computer. When I see a non-trivial problem, the first question I ask myself is — if I had any tool of choice, how would I express the solution? Then, more often than not, the most beautiful answer found goes to the remote bookshelf.
This time I’m lucky to be part of this project that has a very clear superobjection of its own.
Parsec Frontiers raison d’être
What we are trying to achieve with Parsec Frontiers⁵, the project identity and our responsibility, is building the blockchain economy that precedes — at least in some aspects, and maybe yet as a rough and early sketch — the real-world blockchain economy we may expect to come into our life in the future. This blockchain economy is characterized by the trustless and decentralized nature of the regulation of relations among participants, achieved via onchain smart contracts and decentralized applications.
Just like blockchain exists as long as blockchain peers exist (belonging to peers in the most physical sense of the word), the economy we’re building, the business stage where players act, is functional as long as rules and regulations are implemented. Think of this business environment as a conducting medium. In the absence of an electricity field the particles are chaotic, they move in opposite directions with private and momentary goals, and there’s no current. But as soon as you apply the electromagnetic field to align the goals, the current appears. What we need to make economy efficient to let the current flow, is to align participant interests, and this alignment is achieved by usage of mutually beneficial contracts. Our anticipation is to see this onchain participant interaction, to see the economy current flowing.
It’s worth noting that the importance of the business environment stretches far outside the economical part of the game. With the lack of traditional narrative elements, it also aims to recreate the narrative experience for the traditional RPG audience. In the most simple example, the players who are expecting to get the “bring me five mushrooms from the forest” quest from the NPC to let the game mould the superobjection of their role-playing behavior, they will instead get the “transfer this box from Kepler-37 to HD 177830” job from another player, and some time later eventually they too will become narrators rather than actors in someone’s else play.
A matter of trust
A common idea about the blockchain, the technology that powers Bitcoin and other cryptocurrencies, is that it can “create trust”, or allow two parties to make a transaction “without relying on trust”.
If true, this means we could create a world without a trusted “man in the middle”. We could have financial services without a bank verifying transactions, and we could transfer ownership (of a house, for instance) without a lawyer. But this idea is wrong.
The blockchain does not create or eliminate trust. It merely converts trust from one form to another.
The blockchain does not eliminate the need for trust⁶
It is important to understand that there are different forms of trust, and the quoted article above provides a good overview of them.
Whilst we acclaim the role of blockchain in eliminating institution-based trust, there’s another form of trust that I care more about as a layman. If you have ever used a transport company you understand what I mean.
The contract above is too scaled down to be readable, besides it is written in a language that is very likely foreign and unknown for most of you. Ironically it doesn’t really change a thing for many people like me. I can read it, but I’m parsec far from being able to understand it. There are government institutions around to make sure that the contract (whatever is written in it) is fulfilled, but I still have to find someone who can understand it — or more often I just choose to trust that they are honest enough to eventually bring the thing I need from where it currently is, to where I need it to be.
Needless to say that if I’m not even able to understand the contract, then I am not able to prepare one of my own.
Ethereum, Neo and other blockchains with smart contract⁷ support, come to the stage to give me technical guarantees that the contract is fulfilled. But a layman still has no idea what this contract is about (take a look at the Dapps for Beginners: Two Party Contracts⁸ tutorial to get acquainted with the complexity of a similar example). He still has to trust someone who is able to understand it, or trust the honesty of the transport company — he can choose whom to trust, but he has to choose.
Long story short: trustless smart contracts⁹ are not trustless smart contracts.
Is the complexity an intrinsic property of smart contracts?
No.
Designing a way for our players to be able to create and understand the contracts on their own is a vital necessity of the game. It is also our belief that people of the future will be able to make trustless deals as simply as they are able to discuss them. And it is our responsibility, as engineers, to contribute in letting it happen.
How we took up the runes
In Artplant, we’ve been practicing the data driven and tool driven approach for many years. What does it mean? That designers can make significant changes to the game by editing game design data, and they should see an immediate effect of these changes. They need powerful tools for all kinds of design data manipulation that are of the same quality as that of the tools used by programmers to write code. The importance of tools cannot be underestimated. Tools define what you can do and especially what you cannot do.
What do we mean when we say “design data”? Obviously enough, it’s the assets, or classes of assets — in a very broad meaning of the term: items, locations, actors (NPCs). It’s settings — properties which allow altering various aspects of game functionality in the way programmers have thought about. Finally it’s behaviors — which allow designers to compose functionality in a way programmers might have not even thought of.
While the natural way of defining behaviour is code scripting, it has the drawback of requiring dedicated tooling of high complexity — for creating, editing and debugging code. In the absenсe of tooling, designers won’t be able to use scripting efficiently, and even the most powerful script system would result in an over simplified substandard outcome, and buggy behaviour.
The data however — no matter which data format and form editor you use — rarely possess the expressive power of code. Typical companions of pure data behaviors are deep nesting of data structures, inability to define connections in a natural way, and the demotivating feeling of doing something unappropriated.
The diagram approach combines the best of both worlds. It mitigates the drawbacks, and adds some value of its own. Diagrams are easily converted into any data format of choice, inherit all the capabilities of data manipulation tools, and all other benefits of data representation — including the relative simplicity of content validation, formal intent verification, and versioning. From code they inherit the naturalness and straightness of intent expression and the simplicity of defining connections between actions and data. Finally, diagrams often look simpler to non-programmers, without the psychological threshold they have to overcome with text programming languages. The popularity of diagram based scripting such as UE4 blueprints proves that.
Composing diagrams may become pretty simple, if an amount of work is done to dig the pit of success¹⁰ you want your users to fall into. Type validation, completion suggestion and visual feedback are a designer’s best friends. From the moment the user places the first node, he must obtain comprehensive and timely information of how the diagram can be further extended, and if something is currently wrong with it. If yes, then what exactly can be done to fix the problem.
Since we added the diagram support to our data manipulation tool named Hercules, we have been successfully using diagrams for a wide variety of applications, including AI behaviours, scripted missions and ability execution flow.
Introducing visual smart contracts
You can check this video where Trond explores different approaches to use Hercules for creating visual smart contracts. He covers a couple of examples, which differ in their execution model.
Disclaimer: we’re still at the research stage, and the final version of visual contracts may look very different from what is shown in the video or described in this post.
The first contract defines the behavior of an interstellar gate, and the diagram is used to make a decision. Essentially this contract describes the simple AI that controls the gate, and it is natural to try one of the most common AI decision making approaches, the behavior tree. If you are familiar with behavior trees you will easily understand this example.
The second contract is very different — it is the flowchart. It consists of flow blocks, which have the input connectors at the top and output connectors at the bottom. The execution starts at the Start block, and control is passed sequentially by connecting its output connectors to inner connectors of the next blocks, and so on. Some blocks are action blocks, they perform a function call and instantly return (passing control to the next blocks), but other blocks are event blocks which wait for a certain event to happen before the next block may be executed.
Our flowchart is complemented with asset blocks that represent the data flow that the blocks can use. They are important for two reasons. The first is that they serve as function arguments for actions or events, and the second is that they provide the reader with the instant insight of what assets the contract is working with — accounts, items, locations, deposits. We can think of asset blocks as dramatis personæ¹¹, the main characters of our contract.
While looking at this list may be not enough to understand what the contract is doing, it may be enough to understand what the contract is not doing — for example, if you want two parties to lock a deposit, you may instantly notice if the contract is faulty, if only one deposit block is present.
Asset usage by events is curious, because assets may be used for both setting and getting event arguments. If a certain asset is used as an event argument, it acts like a filter condition, and the event only fires if the condition is satisfied. In the Kill Bill example, the Bill asset acts as a filter condition. An unset wildcard asset is not used for filtering, but for capturing the argument. When the asset fires, the wildcard asset is initialized with the event argument value which can later be used by other blocks. This programming concept is known as pattern matching.
How do events work?
Events like On Kill (with arguments) which happen on the game server — are reported by the game server to blockchain, validated if needed (we want to validate transactions that affect asset values), and stored in blockchain for future reference.
All the events on the diagram are compiled to smart contract functions, and calling these functions means that the event happened. The proof of an event should be passed if required (e.g. reference to the kill transaction). For the timer event, current block time is used, which makes timer precision equal to the block producing interval (about 15 seconds).
Who calls the event function? The one who has the proof and is interested in resuming the contract flow. But instead of making the users to manually call the contract, we want to provide a centralized service which will automatically register, filter and trigger diagram-based contract events.
Does it mean that this centralized service has to be trusted? No. The service can’t call an event callback without providing a proof (which is required by the contract). Can it miss the call? Well, in theory, yes. But then the player can call the function manually to resume the contract. In practice, I hope this won’t ever be necessary.
Decentralized applications and visual contract API
It can be relatively straightforward to convert the Kill Bill example from the open bounty contract to the two party job contract. Or to prepare a two party carriage contract to hire the freelancer Frank Martin to transfer our asset from Kepler-37 (where we bought it) to HD 177830 (where we plan to get profit from selling it). Here’s what we need:
- an action block to grant the freelancer access to our warehouse at Kepler-37
- an event to wait for the asset to be returned to warehouse at HD 177830
- data blocks for the asset and warehouses
But in both cases we need to answer the question — what happens if the contract is not fulfilled in time? In the bounty example, we don’t lose anything but our time, which is still precious enough to care about, but in the carriage contract example we can lose the asset.
Of course we can make Frank lock a deposit of his own, which is transferred to us if the job fails, and that is a sound solution.
But what if one of the players was thinking of that problem, and has come up with his own approach — the decentralized application for the freelancer reputation database! He implemented a well-thought out solution (not with diagram scripts, but with real programming language), stable against various kinds of exploit, and it became the job contract de facto standard. The dapp provides a simple web interface, where we can see that Frank’s reputation is quite high, and also the API, which allows Frank to grant our job contract the privilege of punishing or rewarding his reputation, depending on the contract outcome. The developer also provided the visual contract block library that allows us to make a reputation bond, slash it, and reward with reputation.
Now instead of making a cash deposit, Frank puts his reputation on stack. If he fails to fulfil the contract, his reputation bond is slashed, and it will be difficult for him to get some really good contracts before he manages to restore it with low-paid jobs. But if he fulfils the contract, he’s proportionally rewarded (with some percent of reputation at stake).
Support 3rd party visual contract libraries like the one described above is one of our goals, but of course this may only be possible after the out of the box standard library is polished and proven to be useful and is actually used by players.
A matter of trust revisited
If we manage to provide the visual tool that allows even non-technical players to compose and understand smart contracts, can we say that they have become really trustless?
Even if it is absolutely clear what the diagram does, players still need to trust the technology — in particular, that contracts compiled to Neo VM keep the intent identical to the one described in the diagrams. That is why we are going to release the core parts of the visual contract system — the visual contract compiler and the event service — with an open source license. Open source projects are arguably more trustworthy, as their correctness is provable. Although most users won’t be able or willing to prove it, we believe in open source the same way as we believe in science — backed by the collective mind of humanity (or, in our case, community).
Another reason to release visual contract facilities to open source, and to make them as independent as possible, is the attempt to contribute — with gratitude — to the development ecosystem of Neo, which we are really impressed with.
References
- https://www.imdb.com/title/tt0387779/
- https://vimeo.com/36579366
- http://pierroule.com/ZappaRealBook/TheRFZBook.htm#8
- http://globalia.net/donlope/fz/notes/We%27re_Only_In_It_For_The_Money_Cover.html
- But don’t be surprised to get very different answers to this question when asking different people
- https://theconversation.com/the-blockchain-does-not-eliminate-the-need-for-trust-86481
- While smart contracts in general should not be seen as the replacement of legal contracts, I hope that the purpose of this post justifies the comparison.
- https://dappsforbeginners.wordpress.com/tutorials/two-party-contracts/
- They are trustless in the assumed meaning of the word.
- https://blog.codinghorror.com/falling-into-the-pit-of-success/
For more information please join the conversation on our Discord or follow us on Twitter. Also remember to clap and share if you like this content.
