After a lot of hard work we’re releasing the biggest pact upgrade since last year. Pact 2.4 brings some very significant changes to further establish Pact as the premier smart contracts language for blockchain: formal verification that can be used by the average developer, right in their smart contract code; and a new dependency-management system we like to call “no left-pad”.

Pact 2.4 introduces a powerful new system to allow developers to specify *properties *and invariants right next to their code. Properties are used on functions to establish behavior that must be enforced no matter what inputs are provided, or what state the blockchain database is in, and resemble “contracts” from languages like Racket or Eiffel. Invariants are rules governing database columns, ensuring that no code that ever writes to the database can ever violate those rules, resembling database constraints in traditional RDBMSs.

The big difference here is that these properties and invariants, along with the Pact code itself, are directly compiled into SMT-LIB2 to be verified by the Z3 theorem prover, an extremely powerful tool that can test the entire universe of inputs and database states with lightning speed, ensuring that the code can never violate these rules. It’s unit-testing on major steroids.

You can read all about it in the docs!

Remember when Javascript broke the internet? A developer of a single-function library called “leftpad” (to pad a string on the left, in an extreme example of over-componentization) deleted his library from the Node package manager, removing it from nightly builds that power some of the biggest sites on the internet, causing major downtime.

“Leftpad-itis” also struck in blockchain with the Parity wallet bug. See, originally the Parity wallet was a huge mass of code that took a lot of gas to set up, so the developers decided to share that code in another central contract, making each wallet deployment much smaller. An amateur developer was playing around with the shared code though and managed to delete the central contract, immediately freezing $280M of Ether in broken wallets.

The point is, dependency management — what code your code depends on — is a big deal in software in general, and on blockchain it becomes mission-critical. Pact has always *inlined *dependencies, making it impossible for upstream code changes to break your (downstream) code.

However, this creates a new problem for upstream developers. It’s one thing if somebody imports your “leftpad” code which (unless you’re crazy) doesn’t hit your database. When a downstream dependency uses your service in such a way that database access is involved, you could get into big trouble when an exploit shows up, or you need to migrate your schema. Yes, as a reminder: contracts in Pact are upgradeable unlike some other smart-contract blockchains.

In Pact 2.4, we solve this problem with the bless mechanism. Upstream developers can explicitly allow (bless) or disallow (curse?) old versions of their module, referring to them by the module hash. Blessed old versions will continue to allow database accessing functions to still work, while un-blessed versions will cause downstream code to fail. Meanwhile, non-DB code like leftpad can never break a downstream dependency.

Dependency management is a deep topic that merits more discussion, you can read the docs and we’ll be blogging more about techniques for schema migration with minimal disruption to downstream code.

So head on over to the README and learn how to install the latest Pact today!

The next major release of Pact will not take as long as this one, and will feature some really exciting changes: API definitions, which allow you to define a module signature or interface; full REST API testing of pacts, our coroutines that make multi-transaction coding easy; a sensible gas model; user enum types; and much more!