DEV Community: βετα

Smart Contracts: Execution & Examples

βετα — Mon, 02 Nov 2020 23:41:59 +0000

What is a smart contract? At its simplest, it’s a contract between two parties that cuts out the middleman. Smart contracts digitally facilitate, verify, or enforce the negotiation of a contract, allowing you to exchange money, property, or anything of value in a transparent, conflict-free way. And since a blockchain exists in a decentralized system between all permitted parties, there’s no need to pay intermediaries. Of course, blockchains can present their own problems, but they are faster, cheaper, and more secure than traditional systems, which is why even banks and governments are turning to them.

Two Aspects of Smart Contracts

There are two notable aspects of smart contracts that make them so enticing to clients. One aspect is the non-functional property that blockchain provides, a consequence of block processing’s distributed nature that still maintains its trustworthiness and non-repudiability. While smart contracts’ public key crypto technology is built on many established ideas, theirs is still a novel approach.

The other aspect of smart contracts is a flexibility that allows even non-programmers to specify, analyze, simulate, and ultimately execute them. The non-functional properties of blockchains are especially beneficial in these instances. This really is a contract, a process where multiple involved parties can make a sequence of decisions. And if you trust a central entity, you can delegate the execution of the contract to that entity and use crypto to control who is allowed to do what as part of a contract. This second quality of smart contracts is very much in line with the computerification of other non-technical domains, be it computational law or computational governance.

Architecture for Smart Contract Development

Execution of a smart contract is made simple thanks to blockchain technology. You can deploy a contract to the blockchain and execute it there, benefiting from the guarantees provided by the blockchain. As with any binding contract, it is necessary that the infrastructure itself provides correctness guarantees, which is why various projects are under way to formally verify and enhance the solidity compiler so as to support advanced checking through integration. This is where the importance of the right contract development languages and tools come in handy.

Contract development should rely on a language stack. For contract-style programs, functional languages are useful because they can be relatively easy to verify and can also easily support in-memory transactions. On top of its functionality, language extensions can directly support additional contract needs: decisions, auctions, agreements or resource allocations. Each of those can additionally be broken down into a whole range of configuration options to determine the specific behavior.

In the above diagram, Executable Multi-Party Contract Language (EMPCL) contains language constructs typical in most Smart Contract building blocks. Once a language (or a language extension) is stable, it is easier to write the correct code rather than using frameworks or libraries. Language constructs –at an appropriate level of abstraction– means that most lower-level mistakes cannot be made in the first place. The contract is to some degree correct-by-construction. It also means that there is less code to write, so it’s ultimately easier to understand and review. One can even interactively play with the contracts and explore their behavior or else write test cases that can be executed immediately. There’s even a realistic possibility that non-programmer domain experts could read or write the code.

An Example of a Smart Contract

Below is an example of a smart contract based on trades:

daml 1.2
module Trade where

data TradeData = TradeData
with
buyer : Party
seller : Party
uuid : Text
currency : Text
amount : Int
volume : Int
deriving (Eq, Show)

type TradeCid = ContractId NewTrade

template NewTrade
with
facilitator : Party
observers : [Party]
trade: TradeData
where
ensure (trade.amount > 0 && trade.volume > 0)

signatory trade.buyer, facilitator

observer observers

controller facilitator can
  MakePayment : () do return ()

template TradeProposal
with
newTrade: NewTrade
where
signatory newTrade.facilitator

controller newTrade.trade.buyer can
  AcceptTradeIssuance: TradeCid
    do create newTrade

happyPath = scenario do

authority <- getParty "SunWater"
facilitator <- getParty "WaterLedger"
seller <- getParty "Alice"
buyer <- getParty "Bob"

let
uuid = "abc123"; currency = "AUD"; amount = 1000; volume = 50
observers = [seller]
trade = TradeData with ..
newTrade = NewTrade with ..

createProposal <- submit facilitator do create TradeProposal with newTrade
acceptProposal <- submit buyer do exercise createProposal AcceptTradeIssuance
facilitatorPaid <- submit facilitator do exercise acceptProposal MakePayment

return()

This particular example is formally defined, so no different interpretations are possible and it can be executed automatically.

Smart Contracts and Language

At the moment, the languages most commonly associated with blockchain are DAML, Golang, Corda, Solidity, and FLETA. As you can see, these languages are not beholden to blockchain or even much resemble a domain specific language specifically intended to represent contracts. These are often common general purpose languages. It is but one limitation of smart contracts.

The other is that while smart contracts are ideal when it comes to an exchange of virtual assets or to transfer data, they still aren’t quite capable of replacing real-life contracts when it comes to the physical exchange of goods. For all of its benefits in business, it still cannot operate changes on the real world or measure them directly. The highly specific language of legal documents and the highly specific technical language of developers don’t always overlap. But in an increasingly online world, smart contracts will continue to be the go-to for most readily transferable assets.

Transparent and conflict-free, smart contracts’ non-centralized attributes and ease of construction make them ideal for more and more transactions. Thanks to their flexibility and fluidity, the demand for smart contracts will continue to grow as more businesses, banks, and even governments pivot towards them.

Distributed Applications: Building More Completely with the Right Tools

βετα — Mon, 05 Oct 2020 13:25:04 +0000

In my previous post, we discussed the exciting, entirely new business opportunities that now exist in the blockchain space identified the four key pillars that comprise the Distributed Application. We then detailed the first two pillars: “Abstract away the infrastructure” and “Bring Agile to applications.” For this post, we will now turn our attention to the third and fourth pillars.

Third pillar: Provide tools to build complete applications.

Build complete application, integrations, automations, user-interfaces. Smart contracts running on a blockchain are but a small part of possible applications for DAML.

Fourth pillar: Make cheap, fast and complete deployment targets available.

We are trying to make the road to production as smooth as possible. With DAML, your development team can write code once and deploy anywhere.

What’s a Distributed Application?

Let’s take a step back and clarify what we mean by Distributed Application. DAML is a purpose-built smart contracts platform aimed at creating multi-party workflows that come with strong privacy, rights, and obligations guarantees. DAML applications can run on an array of DLTs / blockchains and databases without requiring any changes. As the saying goes: “Write once, run anywhere.” Your favorite programming stack (React, .Net, Java, Python etc.) will work with the DAML smart contract layer.

It’s not quite correct to say that DAML runs its applications on Blockchain, in that we don’t classify applications by the infrastructure on which they run. Instead, DA has these defining distribution characteristics:

Distribution in terms of infrastructure. DAML does not run on a single physical machine. Software engineers know that every large application now falls under this category.
Distribution in terms of trust. There is no central point of trust or fulcrum through which all information flows. Take for example encryption: messages that enter encryption remove the operators’ ability to read our messages.
Distribution in terms of control. Systems where there is no single entity means there is no power to materially disrupt an entire network. Social networks and the internet itself are a good example of this.
Distribution in terms of knowledge. Information only flows to real stakeholders of pertinent information. Peer-to-peer messaging such as email is an example. Email gets read by you, the recipient, and the people who route it in-between, but no one else.

Now, none of these distribution characteristics are new, novel, or have anything specifically to do with blockchain. Most inter- and intra-business applications need most of these properties and that’s why so many systems are now message-based. But at the same time, these message-based systems tend to be error-prone, requiring a lot of data duplication and heavy reconciliation, all of which is expensive. In these systems, cost and value are inversely proportional. Robust infrastructure is expensive, as is running it with specialized personnel.

This is where blockchain’s great innovation comes in. Blockchain provides consistency and brings integrity to a system. It removes the need for duplication, error scenarios, and the need for reconciliation. On top of that, smart contracts give us a mechanism for shared understanding for the rules of such systems.

So how does that change the cost equation? Once such infrastructure has matured and been made interchangeable, you have easy access to managed offerings. In the blockchain world, large tech companies are coming in now and offering properly productionized infrastructures. That’s what we target with DAML. Once that’s established, skillsets and personnel become freed up and increasingly available, allowing for even further innovation. Developers can focus on the application logic and the code that differentiates offerings and brings value to the customer.

What’s Next?

Abstracting infrastructure is only part of the story for Distributed Applications. The current infrastructure abstraction that DAML offers makes applications portable between different platforms and is an important stepping stone in the future of blockchain technology. There’s more ahead in the months and years to come.

Building Business Opportunities with Distributed Applications

βετα — Thu, 24 Sep 2020 15:06:00 +0000

What do the mainframes of the 1960s, the databases of the 1990s, and the blockchains of the past decade all have in common? With every new generation of technological infrastructure, the changes start at a very low-level and ripple outwards, soon reaching an inflection point wherein the technology explodes, transforming the very way that business is conducted globally. Every time after that initial explosion comes a consolidation, where the infrastructure becomes abstracted away and applications themselves become the focus. And that’s when the real innovation starts happening.

“Blockchain” can mean any platform that adds consistency guarantees and commonly includes some form of applications running on these platforms. This technology can bring new properties to an existing category of applications and we don’t need to invent a new blockchain application to get value from technology. Rather, we need to get the technology to support these existing applications.

Take a traditional blockchain example that everyone knows: Bitcoin. It’s the original blockchain app and it remains a high-value application. Blockchain remains highly valued and closely associated with such digital assets, but so far it has rarely ventured beyond such core use. DAML sees the potential to take some of these ideas and apply them to other branches of business beyond cryptocurrency.

We currently find ourselves at such an inflection point. Realizing the historical parallels to these other technological paradigm shifts over the decades, we see in the distributed ledger technology (DLT) of the blockchain space entirely new business opportunities that are well within reach. With this post, we will show examples of the changes and new opportunities that lie ahead in the near future. For this piece, the examples chosen are non-financial, but everything is transferable to the financial sector and other business opportunities.

To clarify, DAML is not a blockchain platform. DAML is an open source tool stack developed by Digital Asset that allows developers to build and deploy distributed applications that run on top of these platforms. We want to enable development teams the world over to build value. But in order to do that, they need to put the application first.

We identify four key pillars that comprise the Distributed Application:

First Pillar: Abstract away the infrastructure.
Second Pillar: Bring Agile to applications.
Third pillar: Provide tools to build complete applications.
Fourth pillar: Make cheap, fast and complete deployment targets available.

With this post, we will look at the first two pillars.

First Pillar: Abstract away the infrastructure.

Putting value first means that you need abstraction. Developers can write a program once and just deploy it anywhere it fits, utilizing DLT, blockchain, cryptographic database or any other similar system. Developers generate business value by focusing on the app instead of other structural concerns.

The benefits can then flow to all sorts of applications. For example, let’s look at project management. These have lots of features, automations, and integrations, features that are seemingly far away from the monetary aspect of blockchain technologies. So nobody would think of this as a blockchain application, but there are strong distributive components, especially centered around qualities like trust, knowledge, and control. A lot of sensitive information gets shared in a project management application and we get used to these applications being centralized, so we work around such limitations.

Second Pillar : Bring Agile to applications.

Distributed Applications need Agile in order to keep pace with the modern business world. With iterative scaling, developers can go all the way from a Proof of Concept built-in base to the scale of a national infrastructure. An Agile approach becomes crucial for minimizing risk and reaching solutions quickly.

Every cycle accumulates risks and costs, so keeping a short cycle is important. Agile allows us to test a product hypothesis with minimal resources, deliver a complete product to customers, and iterate quickly and do regular releases. To allow for rapid development and scale to significant size, we need that infrastructure, upgradeability and tooling to allow developers to be Agile to scale. DAML’s smart contracts can unlock all kinds of new business opportunities and there is more to come.

In the next post, we will examine pillars three and four to see how each of these pieces works towards the modern conception of working with tools like DAML.