Kadena is hard at work offering new and improved visions of the blockchain industry and its tooling. In particular, the Pact team is happy to announce improvements to the Kadena public blockchain Pact API in conjunction with developments and new additions to the language itself. As Kadena matures, we are bringing a new focus to the User Experience/Developer Experience of the platform and its tools, which includes envisioning future L2 solutions in the ecosystem. To initiate these efforts, Kadena presents the following new features:

Zero Knowledge Primitives

As a result of the new collaboration between Kadena and Electron Labs, Pact has included several new built-in functions that allow users to build zero-knowledge solutions.

• pairing-check: performs the pairing and final exponentiation points in BN254 curve pairs.
• point-add: adds two points together that lie on the curve BN254. Point addition is either in F_q or in F_q^2.
• scalar-mult: multiplies a point that lies on the curve BN254 by a scalar integer value.

Together, these natives provide the basis for Zero-Knowledge proof construction and verification. While proof generation is still something the user would need to supply in the meantime, this allows at least the point calculation and proof verification to exist on-chain, providing a strong cryptographic witness to ZK proofs in a decentralized execution environment.

Improvements to Formal Verification

The Pact team recently welcomed Robert Soeldner to the team as a Haskell developer and as the point person on Pact’s built-in formal verification engine. Within a relatively short period of time, Pact has ended up with many upgrades to outstanding bugs in the FV system, as well as a wealth of UX advancements to the surrounding instrumentation. Among the fixes are enhancements to the typechecker and various outstanding warnings for known issues with certain built-ins like select, in addition to the ability for users to study SMTLib output on a per-module basis using the verify debug flag overload.

Bringing Errors Back to the Blockchain

One of the sorely missed features that went away in the most current iteration of the Kadena public blockchain was error output from the /send endpoint. This created a lapse in error coverage, where the /local endpoint, Kadena’s node-local transaction simulation endpoint, was not robust enough to provide accurate error messages./send, the previous means by which transaction errors were generated, now failed to do so. Hence, we decided to improve the /localendpoint to the point where it would all but subsume transaction simulation using /send. While we at Kadena understand that this was a rather difficult period for users, we are offering a two part solution in two separate installments:

1. /local now features a pre-flight simulation api, which brings /local transaction simulations as close to /send as possible: all transaction metadata is validated as it would be in /send, transaction execution covers the full breadth of gas costs from transaction size to the cost of gas purchase in addition to the cost of running the function, and the new API is fully backwards compatible with existing /local-based workflows! Read more about it here: https://github.com/kadena-io/chainweb-node/pull/1585
2. /send in future node upgrades, will default to an error code API that will allow users to query for transaction errors on chain using our Chainweb Data offering. This offers two benefits that are important to consider for the scalability of the system as more and more users pour in: we don’t have to store brittle error messages on-chain, and error codes are much less prone to exploits that lock in error formats as they currently exist in Pact, allowing us to change internal representations in Pact without affecting on-chain semantics.

We want to hear from you as we improve the UX/DX surrounding errors in Pact and its APIs. User feedback is taken into consideration at all steps of the improvement process.

Please make your voice heard on our issues!

A warning system for Deprecations

As Pact gears up for its eventual Pact Core migration, some features are being deprecated in the lead-up to the release. In order to make these deprecations known, rather than writing an article for each deprecation in the cycle, Pact now features a system that provides a warning when certain constructs that are going to be deprecated are in use. Additionally, when one goes to use the /localpreflight simulator, the endpoint delivers any relevant warnings in the transaction execution workflow as a message returned along with the result of execution.

Conclusion

Kadena continues to improve the existing Pact story for both users and developers while Pact shapes up for its migration to Pact Core. As we charge forward with new improvements at our current blistering pace, we also can’t forget how incredible it is to see community involvement in both the design process (in issues, on pull requests), and actually submitting content to the language. In particular, we’d like to thank new contributors @qooboodoop and @omahs, who provided great progression to the Pact service defaults and documentation, respectively. We hope to see more from the community as we grow and see more adoption.

Visit us on GitHub to read the full Pact 4.6 release: https://github.com/kadena-io/pact/releases/tag/v4.6.0

Pact 4.6 is In (pre)Flight was originally published in Kadena on Medium, where people are continuing the conversation by highlighting and responding to this story.

When interacting with smart contracts on Chainweb, one will often see module names or module member expressions prefixed with static names such as free, or util, or kaddex (e.g. free.radio02.direct-to-send). We refer to these static prefixes as “namespaces”, and they form an integral part of the Kadena ecosystem that allows developers and users to write contract and keyset definitions within a private namespace that they govern themselves. What’s interesting about namespaces in the Kadena public blockchain in particular is that the method by which these namespaces are allocated is defined in a smart contract itself within the root (i.e. empty) namespace. This root namespace has special status in the blockchain as one of the few contracts that the Pact application layer is aware of explicitly during transaction execution.

In the past, the means by which new namespaces were allocated was a centralized process, with the namespace contract owners (the Kadena team) operating in a similar manner to a root name server, writing namespaces to a registry upon request. However, now that development is rapidly taking off in the Kadena ecosystem, the Kadena team is introducing the first in a series of steps to decentralize the registration process and delegate namespace definition to the users, allowing them to create namespace names derived from their chosen means of governance.

This article serves as an introduction to the concept of namespaces, how they operate within Kadena, and how the new decentralized process works for users. If you’re already familiar with namespaces and how they work, then feel free to skip to the last section.

What’s in Name(space)?

Kadena’s namespaces are relatively simple in practice. They are used in exactly two scenarios:

1. Contract definition, in which a module is published to a namespace, which allows one to access the module and its members by prefixing the namespace and a dot (e.g. if you have a namespace my-namespace, then if you define my-module within it, you may access its members by issuing my-namespace.my-module.my-function.
2. Keyset definition, in which a keyset is defined within the namespace, and may be referenced by its name prefixed by the namespace name in which it was defined. This allows for keysets to exist with the same name, allowing the namespace to distinguish which keyset with a common name is being referenced at a particular point in code. This also works for named keyset references.

There are two builtins needed to define and “enter” a namespace in order to define constructs: define-namespace, and namespace. Upon defining a namespace, a user and admin governance protocol (a keyset or more generally, a guard) must be supplied in order to define the namespace and who may upload to it. For a more in-depth discussion, see the Pact Language ReadTheDocs.

All in all, the process is fairly simple. To define a namespace one must only issue the following:

(define-namespace "my-namespace"
 (read-keyset "my-admin-keyset")
 (read-keyset "my-users-keyset"))

And optionally, if one doesn’t want to continually prefix module names by a particular prefix during the definition process, the user should issue:

(namespace "my-namespace")

Now you’re off to the races. All definitions will be prefixed with a namespace aside from keysets, which must be defined explicitly with the prefix in mind. The administrative and user guards specifically refer to who “owns” the namespace (who may administrate operators and general code owners), and who has rights to publish definitions within the space (the users/operators).

Namespaces in the Blockchain

In practice, when interacting with the Kadena public blockchain, the Pact application layer implements the means by which namespace resolution is achieved, so there is a bit of knot-tying that needs to happen in order to resolve properly. At genesis all foundational contracts were uploaded to the root namespace, which was reserved for special definitions. One of these was the namespace contract called ns, which provided the resolution logic and registry table for namespaces.

The transaction execution layer points to a particular function in that contract called “validate” which provides the compile-time direction for resolving namespaces via the namespace registry table. This is where the magic happens. The namespace contract is not “special”, per se, in terms of upgradeability or ownership; the logic by which names are resolved can be changed as demands change within the ecosystem. This is an extremely overpowered and underlooked feature unlike any blockchain: namespaces and their associated resolution policies are built to scale with the blockchain, and are immediately amenable to decentralized governance.

Autonomously generated namespaces

As a first step towards decentralized namespace definition, Kadena has decided to offer autonomous namespace definition derived from a keyset, and we’re calling such a definition a “principal” namespace. These namespaces are principal in the sense that they are autonomously reproducible from the administrative keyset, and globally unique as a result. The process is fairly simple, but does require a little knowledge in order to get started.

Kadena has upgraded its mainnet namespace contract (ns) to add a function which the user may call in order to generate a principal namespace name they can use without registering with the ns registry, as well as a change to the way namespace validation is done in order to allow users to begin using their principal namespaces with no further work. As a caveat, such principal namespace definitions are only available for single and multisignature keysets.

To create a principal namespace, one only needs the keys they wish to administrate the namespace, and to call the new create-principal-namespace function exported from ns. In code:

(ns.create-principal-namespace (read-keyset "my-admin-keyset"))

This creates a string that looks like the following:

"n_c1a583206e24450af26de41110042b019695db8c"

This is opaque, and analogous to an IP address. The n_ prefixes a hash of the keyset in order to denote that it’s a namespace, in the sense that http:// prefixes an address using the HTTP protocol. Their use is rather simple — they can be used to define a namespace in the following manner:

(define-namespace
 "n_c1a583206e24450af26de41110042b019695db8c"
 (read-keyset "my-admin-keyset")
 (read-keyset "my-users-keyset"))
(namespace "n_c1a583206e24450af26de41110042b019695db8c")

When a user defines a construct within this namespace, they may begin using it immediately with no further effort.

What about vanity namespaces?

The immediate response to this is obviously going to be: “What an opaque format! Can’t I have something like the cool kids with the .eth domains?” The answer is that the current functionality is a stepping stone on the way to vanity domain names in the same sense that the ENS-style name mappings resolve names to contract addresses. The current iteration at the very least achieves decentralized namespace definition, and is a necessary step to scaling the Kadena blockchain for developers.

Conclusion

I hope this whirlwind tour of namespaces has been helpful for everyone! We strive to provide as many updates as possible as Kadena continues to innovate. We have a bright, bullish future ahead of us as we continue to unlock the power of decentralization and scalability for our ecosystem developers. Stay tuned for 2023 — there’s far more to come!

An Introductory Guide to Kadena Namespaces was originally published in Kadena on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kadena is releasing a new version of Chainweb Node, version 2.17 which will have a service date in effect as of 2022–12–01T00:00:00Z. In addition to various bug fixes and performance optimizations, this release will change the current Pact and Chainweb Node experience for some dApp developers and users. In this article, we will explain the UX/DX-relevant changes in depth, and provide a migration path.

Namespaced Keysets

As of Pact 4.4, we’ve introduced the concept of Namespaced Keysets, which changed the Pact developer experience in favor of more flexibility and security. As of Chainweb 2.17, Pact 4.4 will become the new node standard. For a more detailed explanation of how this will affect users and developers, we wrote about this in a previous post.

Removing Error Details from /send endpoint

Pact features rich error messages to help builders debug problems and handle failures in production. However, this has caused problems for recording transactions on the Kadena blockchain, which has to preserve bit-for-bit behavior for every block. For example, if a miner builds a binary with a slightly different library version, an unexpected error can result in different hashes for blocks. To resolve this, error details and stack traces will no longer appear in failed transactions sent to the /send endpoint, but the error type is still available. This also gives some performance gains by not computing code to assemble the message.

Full error messages are still available using the /local endpoint, and builders are recommended to use /local to execute pre-flight simulation, which is the best practice anyway, and can detect errors before submitting to the blockchain and spending gas.

Fine Tuning the Gas Model

In previous Chainweb node versions, our work centered on fixing various security threat vectors, which affected the gas model. As we work to fine tune the gas model, we’ve actually found a way to make operations such as transferring coins cheaper than ever before. Developers will want to recalibrate the gas limits they use for transactions. You can see how much a gas a particular transaction takes using the /local endpoint for pre-flight simulation.

Node Performance and Bug Fixes

In addition to the above changes, Chainweb 2.17 features the following performance improvements:

• Improved performance during catchup
• Improved P2P protocol performance
• Improved TLS session management
• Faster and safer binary serialization across the board

Along with the following bug fixes:

• We now protect against possible race conditions in SQLite interface code
• Chainweb 2.17 features a per-tx timeout during creation of new blocks to prevent mining nodes from stalling when block creation takes too long

Summary

The Kadena public blockchain is constantly evolving to meet the demands of dApp developers and bring innovative technology to the forefront of the crypto industry. We are listening and addressing feedback as it comes to us, and providing bull-market solutions in a bear-market winter. We welcome your feedback, and hope to hear more from builders.

What’s new in Chainweb 2.17 was originally published in Kadena on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kadena aims to continue building and supporting our developer community with a robust, best-in-class experience for Web3 developers. In order to do so, the team at Kadena continues to provide developer updates swiftly to ensure a smooth builder experience.

This article will inform you on how to migrate away from two guard types in Pact to safe alternatives. These deprecated guards will be removed in a future release.

Overview

Module and pact guards were designed to allow autonomous code to control funds in an era when all Pact code execution paths were known at compile time. The later introduction of module references allowed untrusted third-party code to be executed within module code, rendering module and pact guards unsound. The solution is to migrate your code to capability user guards.

While code that does not involve module references can safely use module and pact guards in some cases, capability user guards are still less bug-prone. For this reason module and pact guards are considered deprecated and all user code is recommended to exclusively employ capability user guards in cases where module and pact guards would previously have been used.

Module & Pact Guards considered harmful

The original design of Pact offered autonomous guards largely modeled after the ownership model presented in the Ethereum EVM, where “contract accounts” simply hold ETH alongside code that can use those funds however it sees fit. In Pact, this was generalized into module guards, where the guard would pass as long as the code was being called from the module associated with the guard, and pact guards, which only pass if a specific instance of a defpact is executing.

This, of course, meant that module code invoking the guard-handling code had to be protected by other predicates and capabilities. As such, the code could have bugs as there was no explicit authorization, or scoping of said authorization. Capability-based guards solve these potential issues.

However, the later introduction of module references now brings third-party code into the mix, with the unfortunate property that anywhere the owning module calls into module reference code, that third-party code now passes the module guard. This is also true for defpact guards: while the current Pact ID is validated, invoking modrefs in any way will pass the guard.

Fortunately, building user guards using require-capability offers a truly secure mitigation. Capabilities now secure and scope guards alongside critical module code. All of the features that make Pact capabilities sound are now extended to guards for robust autonomous resource ownership.

Capability User Guards

Capability User Guards are a design pattern for safe autonomous guards in Pact. They are composed of three code elements: a capability, a predicate function, and a user guard. The latter can be offered as a “constructor function” resulting in a trio of definitions that defined together clearly present the overall guard structure.

Migrating Module Guards to Capability User Guards

A typical use of a module guard is to allow a smart contract to control KDA funds. For instance, the following deprecated code transfers money into an account owned by a module guard.

;; DEPRECATED module guard example. 
(coin.transfer-create funder BANK_KDA_ACCT (create-module-guard "bank") amount)

The problem with module and pact guards emerges when invoking the guard to do critical operations like withdrawals.

The core enabling feature of Pact powering this mitigation are capabilities, which already serve to secure critical pact code. Modules using the above bank code might have code that looks like the following:

;; typical Pact code for protecting a critical operation.
(with-capability (WITHDRAW recipient amount)
  (coin.transfer BANK_KDA_ACCT recipient amount))

With a module guard, there is potential for the first code block to be unsafe. However, by creating or rotating the BANK_KDA_ACCT with a capability user guard, this same withdraw code can be 100% safe with no changes.

A capability user guard definition

;; Capability user guard: capability definition
(defcap WITHDRAW (recipient:string amount:decimal)
  ... ;; enforcement of WITHDRAW capability
)

;; Capability user guard: capability predicate function
(defun require-WITHDRAW (recipient:string amount:decimal) 
  (require-capability (WITHDRAW recipient amount)))

;; Capability user guard: guard constructor
(defun create-WITHDRAW-guard (recipient:string amount:decimal)
  (create-user-guard (require-WITHDRAW recipient amount)

Armed with these definitions, the original funding code can now be migrated to read:

;; Migrated module guard example using WITHDRAW capability user guard.
(coin.transfer-create funder BANK_KDA_ACCT 
  (create-WITHDRAW-guard funder amount) amount)

… and the withdrawing code above will continue to function with no changes. Migration complete!

Employing composition

The problem with the above migration is the over-specificity of building the guard around the WITHDRAW capability: for instance, the above code only allows withdrawals of the same amount that was originally funded. If WITHDRAW is invoked with a different amount, the guard will not pass.

The opposite end of the solution spectrum is a parameter-less capability that serves only to fulfill the conditions of a capability user guard, which is then composed into the WITHDRAW capability.

;; Invoking capability definition
(defcap WITHDRAW (recipient:string amount:decimal)
  ... ;; enforcement of WITHDRAW capability
  (compose-capability (BANK_DEBIT))
)

;; example of other capability also needing debit
(defcap PAYMENT (recipient:string fee:amount)
  ...
  (compose-capability (BANK_DEBIT))
)

;; Capability user guard: capability definition
(defcap BANK_DEBIT () true)

;; Capability user guard: capability predicate function
(defun require-BANK_DEBIT () 
  (require-capability (BANK_DEBIT)))

;; Capability user guard: guard constructor
(defun create-BANK_DEBIT-guard ()
  (create-user-guard (require-BANK_DEBIT)))

You would then create the account using the BANK_DEBIT guard:

;; Migrated module guard example with BANK_DEBIT capability user guard.
(coin.transfer-create funder BANK_KDA_ACCT 
  (create-BANK_DEBIT-guard) amount)

Best practice: Be as specific as possible

While capability user guards require the least boilerplate when using a parameter-less capability, it is best to “de-parameterize” only as much as needed to serve the indicated use cases and no more. For instance, if WITHDRAW was the only bank-debiting operation in the above example module, and was explicitly designed to withdraw exactly what was funded, then the WITHDRAW-based capability guard is actually safer by limiting cases where the guard would fire. Indeed, it suggests a design that supports UTXO-like accounts, with the WITHDRAW capability guard perfectly suited to support multiple accounts that support only a single deposit and withdrawal.

When migrating, keep an eye out for code that relies on a single resource + module guard which could be improved by decomposing into separate resources. For instance, if user and autonomous monies previously shared the same KDA bank account, using two accounts protected by the distinct capability guards is potentially a safer design.

Migrating pact guards

Pact guards must be migrated to capabilities that are explicitly parameterized with the intended pact ID, and enforce equality with the current pact ID. Beyond that, they are identical to migrations for module guards.

;; simplified marmalade-style sale second step capability
(defcap BUY (sale-id:string token-id:string buyer:string price:decimal)
  ...
  (compose-capability (SALE_PACT sale-id))

;; Pact capability user guard: capability definition
(defcap SALE_PACT (sale-id:string)
  ;; all capabilities for guarding pacts MUST 
  ;; validate that the current pact ID matches the
  ;; parameter value.
  (enforce (= (pact-id) sale-id) "invalid sale id")
)

;; Capability user guard: capability predicate function
(defun require-SALE_PACT (sale-id:string) 
  (require-capability (SALE_PACT sale-id))

;; Capability user guard: guard constructor
(defun create-SALE_PACT-guard (sale-id:string)
  (create-user-guard (require-SALE_PACT sale-id))

In a marmalade-style sale, BUY guards the second step. In the first step, instead of using create-pact-guard, you would use the capability user guard with the current pact ID to guard the NFT escrow:

(let ((sale-id (pact-id)))
  (ledger::transfer-create token-id seller (create-sale-account sale-id)
    (create-SALE_PACT-guard sale-id) amount)))

Now, you are all set and the pact guards have now been migrated!

We hope that you found this article to be helpful! Please share your feedback with us on our Discord channel or on our GitHub repository! Be sure to follow us on Kadena’s social media accounts for more developer updates and news as Kadena continues to drive innovation on the blockchain!

Deprecation Notice for Module Guards and Pact Guards was originally published in Kadena on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every growing decentralized community needs builders. With the new cohorts of grantees selected by Kadena Eco being announced every week, the Pact engineering team has been hard at work soliciting feedback and developing features for dApp developers to build their projects with more security, robustness, and confidence than ever before. Pact 4.4 brings major improvements in functionality, auditability, and transparency — primitives for building the decentralized economies and marketplaces that continue to dominate crypto.

Among the changes Pact 4.4 will bring to the ecosystem is a general move towards namespacing and principal account protocols becoming the norm. This is in response to several improvements identified over the course of the Kadena Improvement Process for `k:` account protocols that enable more robust methodologies for working with on-chain governance. Kadena is introducing the following as features for the language and network:

Namespaced Keysets

Keyset names have historically been un-namespaced, living in a global keyset registry on each chain. Due to the growing network contention for keyset names, as of Pact 4.4, all newly defined keysets will be required to be namespaced going forward. While in most cases, users never interact with keyset names, this will affect dApp developers and builders using Pact who wish to define smart contracts using their own custom governance, defined within their chosen namespace.

As an example, in code:

There are few times when a keyset name is of importance, and are limited to a few use cases:

• enforce-keyset/enforce-guard
• keyset-ref-guard
• define-keyset
• keyset name module governance

This change applies almost exclusively to builders and power users who are writing their own smart contracts or engaging in more sophisticated governance methods. This should make things less ambiguous for everyone!

Adding this feature also allows Kadena to lay the foundation for principal-namespaces — a feature that will be introduced to the community in the upcoming weeks.

Note: legacy keysets *are not required to migrate*. This change only applies to newly defined keysets. That is, legacy keysets will still work, and still be rotatable.

Gas adjustments for Format and Try

Gas was previously too lenient for both `format` and `try`, and has been adjusted to be more accurate with respect to its actual computational cost. This results in contracts that make use of either function to cost slightly more gas.

Most notably, KDA transfers via coin.transfer, coin.transfer-create and coin.transfer-crosschain will use more gas. Tool and dApp developers (such as wallets and exchanges) should adjust their gas limits appropriately.

These continuous improvements to our gas-model will eventually lead to adjustments in blocksize, but because of large effects that small lowlevel changes can have on network health, prudence dictates a conservative timeline for the rollout of these changes.

MUSL-based mathematical primitives

All the transcendental math functions in Pact (log, ln, exp, sqrt and pow) now rely on implementations of these functions from the MUSL library (https://www.musl-libc.org/). With this change, the implementation of these functions is now in high-precision plain C, allowing more consistent behavior across platforms, compilers, operating systems and processors. Previously, differences in how these functions were realized by the Haskell compiler could lead to scenarios in which values differed ever so slightly — enough to result in hash mismatches causing block validation failures and an inability to advance the chain for some nodes.

Please share your feedback with us on our Discord channel to help us improve tooling for our builders.

What’s New in Pact 4.4 was originally published in Kadena on Medium, where people are continuing the conversation by highlighting and responding to this story.

Learn all the ways Pact 4 accelerates safe smart contract development

Smart contracts are all about making things happen — every transaction on the blockchain records assets changing hands, or community members committing to support a project. With Pact 4 the safest and easiest smart contract language gains powerful new features to ensure apps ship with the most security, transparency and kickass functionality possible. With new community-driven primitive ops, better cross-chain and event support, and code coverage, Pact 4 is the most productive smart contract language ever.

What’s new in Pact 4?

Pact 4 brings major improvements in functionality, auditability, and transparency, things that are more important than even as decentralized economies and marketplaces continue to dominate crypto.

Great new community-demanded primitive ops

There are more Pact developers than ever before and with that comes positive pressure on the language to grow new powerful features that continue the Pact philosophy of “safer doesn’t mean weaker”: indeed Pact 3.x already ships with more built-in functionality than any smart contract language around. Still, devs will be devs and find new itches to scratch as well as corners where Pact could be even better:

String abstractions: while Pact already ships with a full toolset for manipulating strings, some more advanced concepts were hard and gas-expensive to implement, and as Pact devs get more sophisticated they have identified some gaps: namely, the ability to treat a String as an array, or list of characters, as well as more list manipulation tools.

With the new str-to-list builtin, Pact devs can cheaply convert in order to use Pact’s powerful functional list operations like map, filter and fold on a list of single-character strings. Of course, it would be unsporting to not be able to convert back, which exposed the need for the common concat operation — while already easily achieved with (fold (+) “” …), familiarity with concatenation makes it a good pair for str-to-list as a bidirectional transformation — a pair of functions devs can keep in mind when needing to perform advanced operations on strings.

More list operations: Pact, as a LISP, is all about lists, and in its full generality allows for every operation imaginable if you can express it, all within a Turing-incomplete language. However, like concat, some operations are just better handled as built-ins, which again the community noticed. Things like de-duplicating list entries with dedupe, or emitting series of numbers with enumerate, offer gas-cheap ways to do these useful things and focus more on business logic.

More support for blockchain “Events”

More ways to emit events: Pact already has a great mechanism for events, which form crypto-verifiable “facts” that are critical for indexers and for cross-chain operations on Kadena and EVM chains alike. The new emit-event built-in makes event firing “free” as opposed to using with-capability which invokes the capability even if it’s an empty event. However, emit-event also allows managed capabilities to have arbitrary parameter values when used as events. For example, the fungible TRANSFER capability emits the TRANSFER event, but only for valid “balance-conserving” transfers like “Bob gives Alice 10.0 tokens”. With emit-event, TRANSFER can also be used for “burns” and “creates” using the empty account (“”), which would never form a valid TRANSFER capability, but follows ERC-20 and related standards for burn and create event emission in a way that indexers and exchanges expect.

Cross-chain Improvements

Built-in cross-chain events and upgrade back-compatibility: Pact has the best cross-chain story of any smart contract language thanks to defpacts, which automatically handle cross-chain transfers for any asset imaginable with zero developer effort. However, it was hard for indexers to be aware of these occurrences; and worse, if a smart contract was upgraded, it could mean that a cross-chain initiated beforehand could become permanently “orphaned”, as the security check for cross-chain demands that code hashes match on both sides; after an upgrade this would fail.

In Pact 4, the already existing bless mechanism, which allows old versions of smart contract code to continue to support old users, now also supports cross-chain transfers that span an upgrade with the inescapable hash change. Plus, Pact now automatically emits X_YIELD and X_RESUME events for every cross chain, meaning that devs no longer have to worry about indexers tracking their cross-chain events.

KDA coin contract v3!

KDA support for more events: version 3 of the coin contract for KDA takes full advantage of new Pact 4 features to emit TRANSFER events for every event on the blockchain, whether that’s miner rewards, gas payments, or cross-chain burns and creates. It blesses the previous hash to ensure that midstream cross-chains succeed that occur during the upgrade. Finally it leverages the X_YIELD and X_RESUME events to be the most transparent and indexable platform coin ever. It’s important to remember that unlike any other blockchain, KDA’s economics are implemented by smart contract: so at Kadena, we’re as much Pact users as we are its designers. coin acts as a great cookbook for new developers to study and v3, with Pact 4, is no exception.

Code Coverage

With Formal Verification support and excellent support for unit tests and blockchain simulation, Pact is already the best language for correct, bug-free smart contracts. However, as Pact becomes responsible for more and more value, things like auditing code become critical. Pact 4 addresses a major need by providing code coverage so that devs can immediately see if their code is being fully exercised by their unit tests.

This is of course fully supported in the pact tool by simply adding “-c” to the pact call. In the Atom editor, a quick upgrade to version 2.6.4 of language-pact, plus adding the lcov-info plugin, gives quick access to coverage results. Coverage in Github CI can quickly be enabled with the standard code-coverage-report action.

Start using Pact 4 today!

It’s never been a better time to start learning Pact than now as the Kadena blockchain continues its rapid growth as the “home of DeFi” with every major use-case on its way to production before 2021 is out. Check out the docs, and upgrade by downloading it or using brew upgrade kadena-io/pact/pact.

Get on the inside track and start writing successful, safe and profitable smart contracts in Pact! Check out our developer quickstart at https://quickstart.chainweb.com/ , join our Discord and get hacking!

Get to know Pact 4! was originally published in Kadena on Medium, where people are continuing the conversation by highlighting and responding to this story.

UPDATE Feb 20 2021: Bountyswap is live — start swapping today! Watch instructions on how to connect your Zelcore wallet to Bountyswap.

After a successful and productive run in testnet, Kadenaswap is headed to mainnet to start “Bountyswap” — the live beta! It’s a good time to lay out the current plans for Kadenaswap, Bountyswap and the future of multi-protocol, scalable DeFi.

What is Kadenaswap?

Kadenaswap is a decentralized exchange (DEX) running on the Kadena blockchain, modeled after Uniswap and other “constant product” exchanges. Like those, “automated market makers” (AMMs) provide liquidity for pairs of tokens, so that users may swap one token for another at the ratio currently provided by the pair.

The great thing about this design is how it lives up to the “decentralized” claim: everything from liquidity provision, pricing to swapping is done entirely on-chain, requires no intervention from off chain authorities or oracles, and is fully autonomous with no control by any central on-chain authority either.

Constant Product Exchanges

There are two roles in this style of DEX: the AMMs providing liquidity, and “swappers” accessing that liquidity to swap between tokens. For example, let’s look at a hypothetical altcoin ABC in a pair with DAI, MakerDAO’s stablecoin, “wrapped” on the platform. We’ll talk more about “wrapped tokens” below but for this example, we’ll just call it DAI.

Liquidity provision

To swap ABC for DAI on a constant-product DEX, there needs to be ABC and DAI already there to service your swap. An AMM facilitates this by adding liquidity to the ABC:DAI pair. If the pair doesn’t exist, the AMM can create it, otherwise they add to what’s there. An AMM must provide both ABC and DAI, in a ratio that represents the current “market price” of swapping between DAI and ABC.

Thus, if ABC is trading at USD $0.25, since DAI tracks the dollar closely, an AMM could provide 1,000 ABC and 250 DAI to launch the pair. A remarkable principle of constant-product exchanges like Kadenaswap is that arbitrage swapping ensures the price faithfully reflects the off-chain market:

• If the AMM provides too much DAI, that effectively under-prices ABC, making it profitable to swap DAI for ABC, which will bring the pair back inline with the market price.
• Likewise, if there’s too much ABC, it over-prices ABC, making it profitable to swap ABC for DAI.

Swapping and Fees

Now that the pair is provisioned, a user can come in with DAI wanting to buy ABC, or with ABC wanting to buy DAI. The rate is determined by the available liquidity, as the smart contract enforces the constant product. With 1000 ABC and 250 DAI, that’s the square root of 1000*250, or 500: whatever remains after the swap must compute to something equal or greater than this amount.

In addition, the user is charged a fee of 0.3% of the constant product, either by providing more of one token, or getting less of the other. So the swap in fact must result in the constant product with fee increasing or equal. So, if the user wants to buy 10 ABC worth of DAI, instead of getting 2.5 DAI, they will get 2.467895, and the constant product grows to 500.007426. In this way, the holdings of the pair in the underlying tokens grows with each swap.

Liquidity Token ownership

The constant product also faithfully represents AMM positions in the liquidity pool. In the example above, the first provider gets 500 units of the liquidity pool, out of 500 total liquidity. A second AMM coming in with the same amounts also gets 500, but now the total liquidity has risen to 1000. These holdings are stored in the liquidity token for the pair, which in our example is ABC:DAI.

To access these profits, an AMM removes liquidity. This results in the burning of their liquidity tokens and a redemption of the holdings in the pair tokens in the current ratio. Since this has increased from swaps, the amount of the underlying tokens has grown, and the AMM profits. Note that there is more to this story if the external price has moved, but at least according to the constant product, and trusting that arbitrage has kept the ratio sane, the AMM is strictly richer due to accrued fees.

Kadenaswap: gas-free, multi-protocol, multi-chain, multi-platform

Kadenaswap is designed to take the constant product design that has proven so successful with Uniswap and other DEXs and leverage the unique advantages of the Kadena platform.

First, as an on-chain DEX, Kadenaswap will be multi-protocol from the start, offering any on-chain asset that market-makers want to pool. Unlike many “off-Ethereum’’ DEXes, Kadenaswap pairs are not limited to only super-liquid tokens like BTC and ETH and leading stablecoins, but any fungible asset on-chain, such as protocols that provide unique market access like LUNA and CELO, as well as proven protocols on Ethereum like DAI, and of course all tokens on the Kadena platform.

Thanks to gas stations, trading on Kadenaswap won’t require a user to hold KDA to trade. Even if they did have to pay gas, gas fees on Kadena are currently microscopic (usually ~0.0000000001 KDA). However, this can change if usage steeply increases. If only running on one chain of the Kadena blockchain, gas prices would inevitably go up for the same reason they do on Ethereum: in the face of congestion, increasing the gas price increases the priority for a miner to include your transaction in the next block.

Scaling an on-chain DEX

The real answer to gas prices is scalability. This is where Kadena shines: even the fastest Proof-of-Stake platform has upper limits on throughput, but Kadena’s chainweb protocol uniquely can scale the number of chains to meet any demand. In turn, Dapps on Kadena simply scale out to the number of chains needed to service demand.

So, just run Kadenaswap on multiple chains, problem solved? Well, not exactly. Chains in Kadena still run independently, and a coin “can’t be in two places at the same time”. Each Kadenaswap smart contract on its own chain will have completely separate pools for a given pair. This can mean prices can get out of sync, but that can be fixed by the same arb-ing described above. The harder problem to solve is liquidity fragmentation, where a pair on one chain has way more inventory (and is therefore a better place to trade) than on another chain.

Multi-Venue AMM Incentives

We like to call multi-chain Kadenaswap “multi-venue” to indicate the notion that there is more than one venue where the trade is made. To solve liquidity fragmentation, incentives are needed to reward AMMs for balancing liquidity across venues.

An initial design simply incentivizes AMMs to lock up liquidity in a pair for some period of time, let’s say a week. An AMM can then prove to the same pair on Chain 2 that they are providing equal liquidity on Chain 3 for that same week and receive higher gains accordingly, through either yield incentives, or through a fee structure that rewards cross-chain provisioning higher than single-chain.

This allows pairs to scale independently: if one pair isn’t overloaded on a single chain, it can enjoy an unfragmented market. Meanwhile, a hard-hit pair can scale to as many chains as demand requires, and market makers will be rewarded for splitting up their positions to service each venue.

Finally, insofar as pairs are truly isolated, they can simply exist in separate venues. For instance if some altcoin is really only paired with stablecoins, they can all hang out in a single venue, even though other pools with those stablecoins and other coins are scaled over multiple venues.

If this sounds confusing, worry not: it will be easy to swap and AMM across all chains in Kadenaswap. The hard part is the multi-venue design and incentive structure, which we will be iterating on as we scale. Solving this problem is a first step to building a truly industrial-strength DEX.

Multi-Platform

The great thing about Kadena’s multi-chain structure is that it’s truly multi-chain while still being in the Kadena universe: once it’s in motion, the multi-venue design can then scale onto other Pact-supporting platforms like Cosmos, or Polkadot (once the Pact Core/Kadenadot initiatives are ready).

In this way, Kadenaswap will be the only multi-venue, multi-protocol, and multi-platform DEX, leading to a future where users won’t have to even think about platforms and protocols, but just access value wherever it is.

Bountyswap Live Beta

Bountyswap is a “soft”, live-beta launch of Kadenaswap on mainnet, using a “temporary” token that only has value while Bountyswap is in progress. We expect Bountyswap to run for 2–4 weeks, or longer if issues are found. The goal is to use the temporary token to incentivize “white-hat hackers” to try to break the system and steal coins, which is theirs to keep if their hacks are successful.

“KPenny” temporary Bountyswap token

We call the Bountyswap temporary token a KPenny which gives a hint of its functionality. KPenny tokens can be reserved for use with Bountyswap at a rate of 1M to 1 KDA token.

Bountyswap will then launch three pairs on Kadenaswap, using two “test tokens’’ called ABC and XYZ. The three pairs will thus be KPenny:ABC, KPenny:XYZ, and ABC:XYZ. The bountyswap admin marketmaker will provide liquidity in all three pairs. The target quantities will thus represent up to 100,000 KDA, creating a significant “honeypot” to attract hackers to attack.

At the end of Bountyswap, all KPennys will be returned in the equivalent KDA, and all three tokens will be decommissioned. However, swaps and fees will mean that these values will have changed, and the amount returned will reflect this. This ensures that the “honeypot” will reward the tester if an exploit is found.

This of course also means that any KPenny token reserved for Bountyswap program is not guaranteed to return to its original owner. Indeed, testers need to be aware that their reservations can be entirely lost due to an exploit or otherwise. But in any case, testers will want to swap out of the test tokens before the program ends. Thus, there will be a “shutdown period” where KPennys will no longer be available for reservation and will only support transfers out of pair accounts. During this time, testers can swap out of XYZ and ABC into KPenny in time for the full shutdown.

Get involved with Bountyswap!

The Bountyswap home page has everything you need to get started. At time of writing, Bountyswap is not live as we’re finishing up KPenny functionality in Testnet. After that, use links there to download/connect your wallet, reserve some KPennys, and get swapping and AMM-ing! Don’t forget to join our communities on Telegram and Discord to get support, ask questions, and suggest improvements!

Introducing Kadenaswap “Bountyswap” Live Beta was originally published in Kadena on Medium, where people are continuing the conversation by highlighting and responding to this story.

When getting started with the Kadena public blockchain, the first thing you’ll want to do is create an account so you can start transacting with other users. This article will break down exactly what keys are, what an account is, the myriad ways to create one, and how to add your account to several existing tools. First, we’ll do an extremely high-level tour of public-key cryptography.

What Are Keys?

Keys are everywhere in blockchain land. You might at least be aware that to begin transacting in any network, you have to generate a public/private key-pair. Using this pair of keys, you generally share the public one and keep the private one secret, using the private key exclusively for signing transactions. If this is foreign to you, I suggest you take a look at this lovely StackOverflow summary of the metaphor. A key-pair is easy to generate, and looks a little like this:

public: 4bf1a0b622650367effca85dd6da35a937bc75fdbbdba04ff7d9338262135e98

secret: 0e809ea42eccb4a90caebeef015dd9ef71a8d1cdfcfabfecb446320dd3bfe7d2

Now, the fun part about public/private key-pairs is that a key-pair has the property that the secret key can “prove” you are the owner of the public key through a sophisticated dance (the underlying algorithm), and also has the incredible property that any given key-pair is almost universally guaranteed to be unique. No one will ever be able to produce an exact copy of either key by any reasonable means other than theft. I say “almost,” because there’s still a probabilistically minute chance that someone may end up generating the same key-pair as you, but the time it would take for that to happen is several trillion years from now, sometime around the Heat Death of the Universe — roughly the same probability as your computer spontaneously catching fire during the generation process.

In many blockchains, because of the global uniqueness of key-pairs, accounts are modeled as simply public/private key-pairs or a variation on the theme with additional data like a nonce. This is great and makes things simple, but it runs into problems very quickly from a philosophical standpoint. Consider the following question: what do key-pairs represent? Is it an individual? A couple? A throuple? A polycule? A board of directors? If it’s more than one person, what governs usage policy? Certainly, if a married couple decides to open up a joint bank account, it’d be terrible if one could drain the account and leave the other penniless and without recourse. Indeed, joint accounts require multiple-signature signing to release funds. In the same vein, a board of directors would vote, and a majority of votes would determine what to do with the funds of a company. Let’s call this idea governance predicate.

The metaphor works fantastically well for single-person, single-key-pair accounts, but breaks down in blockchains like Ethereum when a many-to-many relationship and finer-grained multiple-signature governance is needed. Much of the Ethereum ecosystem, for instance, is geared towards finding clever ways to shove the many-to-many idea into a many-to-one box, which ends up being costlier than it needs to be, and frankly, begs a better design. Oddly enough, Bitcoin handles multi-signature accounts just fine.

This brings us to the notion of Keysets in Kadena.

What Is a Keyset?

Kadena natively supports multiple keys governing the same account (multi-sig), so keysets are, to some degree, exactly what they sound like: a set of keys. In addition to a set of keys, every keyset contains something called a ‘predicate function’ that determines which keys are allowed to make choices for the account when it comes to transactions (do all keys need to be present? only one? two? etc.). Summarily, keysets look like the following as JSON data:

{ 
  "keys": ["pubkey1", "pubkey2",...,"pubkeyN"],
  "pred": "some governance function"
}

When signing a transaction, the list of private keys supplied as signing key pairs will be checked against the keyset and predicate to ensure that not only are all keys that need to be present accounted for but that the predicate is satisfied.

Predicate Functions

There are 3 out-of-the-box predicate functions that are available:

• "keys-all": This predicate will require that all key pairs governing the account are in scope when signing a transaction.
• "keys-any": This predicate requires that at least one key pair governing the account is in scope when signing a transaction.
• "keys-2": This predicate requires that at least two key pairs governing the account are in scope when signing a transaction.

Smart contract authors are free to write their own predicate functions if they need more fine-grained functionality, but that is beyond the scope of this article. Feel free to read up more on predicates in the Pact readthedocs.

When Are Two Keysets the Same?

Two keysets are the same when all of their keysets match, and they have the same predicate function guarding the keys. This means that if you have an account defined in the coin contract as the following data:

key: "Emily" -> value: { 0.0, { ["fcca3bc5..."], "keys-all" }}

And someone attempts to transfer-create (see: getting started with transfers) to your account (which checks the keyset against the one supplied by the sender) with the following data:

(transfer-create 1.0 "Emily" { ["fcca3bc5..."], "keys-any" })

Then this will fail because the keyset governing the account is wrong, and the blockchain will see the transaction as someone using the wrong keys to try and access an account. If you imagine a board of directors sitting around and all of them have to be present to make a vote, but some bozo comes in trying to say only 1 of them needs to be there and the rest can go home, that person would be laughed out of the room! The same goes for keysets. Make sure the keys match exactly.

What Is an Account?

Kadena is unique in the fact that there is no global notion of what an account is. Even the KDA token exists as a smart contract in the network! It turns out that in the Kadena blockchain, every smart contract can define their own tables and interact with them in a robust way, defining their own data structures, called schema. These schemas are used inside the contract to define the table structure, and therefore the way the contract will store data. It just so happens that this is exactly what the KDA coin contract does — it defines a table called coin-table along with a schema called coin-schema , which defines the general model for interacting with tokens. The schema is rather simple — row keys are account names, and the data it points to are a balance and a set of keys governing the account. Visually, it looks like this:

key: Account Name -> value: { Balance, Keyset }

In practice, many people are used to the model that blockchains like Ethereum or Bitcoin use, where public keys are considered an “address,” and there is an associated balance. This is very similar to what Kadena has. In fact, if you make your account name your public key, then it looks roughly the same:

key: "f1f6f54914f33..." -> value: { 0.0, ["f1f6f54914f33..."] }

But if you really want to get fancy, then you can have a custom name as your account name:

key: "2Chainz" -> value: { 0.0, ["f1f6f54914f33..."] }

It doesn’t really matter — you just have to remember it! Practically, this is why people just go with a public key as their account name — it’s right there in the keys. As more sophisticated technology comes out supporting the Kadena ecosystem, and as wallet technology gets better and better, tracking this sort of thing will be taken care of automatically.

Creating Accounts

Account creation happens in the blockchain in a few ways:

• When mining to an account and a keyset, when you win a block, the reward will create your account automatically using the keyset and account you specified. By default, if you just submit your public key as the argument to your keyset, then a singleton keyset will be constructed and your predicate will be set to keys-all.
• coin.create-account which allows someone to create a zero-balance new account (note that this costs gas, which would have to be paid by a different account, which is possible with Kadena).
• Someone used transfer-create or transfer-crosschain to transfer coins to an account that did not exist (those functions spontaneously create an account and deposit the transfer amount into it if the account doesn’t exist).

Just creating a public key pair is not the same as creating an account in the blockchain, but it does guarantee that you have a unique account name. Cryptographically, public keys are almost guaranteed to be uniquely generated, so people often conflate the two.

Chainweaver Accounts

Along with its blockchain, Kadena released a wallet for Mac, called Chainweaver, and this wallet allows you to create accounts easily with the click of a button. We’ve done a full write-up of how to create accounts, keys, and make use of the wallet’s numerous features here.

Conclusion

There you have it: this has been a tour of accounts! This is one of the more fundamental aspects of interacting with the Kadena blockchain, and I’m glad you took the time to read about it. We’ve made some great improvements to the way people interact with blockchains, supporting native multi-sig and custom smart contract table design, and we are happy to take on board any feedback you can give.

We also welcome help from the community for documenting these tools and constructing new ones along the way. We are always happy to rep community-blessed tools if they are better than our own. We welcome anyone to contribute to the Kadena Community projects repository with your own project or add to existing ones. So far, the community projects have yielded both a great terminal wallet with Bag of Holding, and a blazing fast GPU miner courtesy of Alex Khonovalov, Edmund Noble, and myriad other insanely smart community members.

Thanks to everyone who contributed, and please feel free to raise your questions to me in Discord — my handle is one of @topos, @pitopos, or @emilypi depending on where I am on the internet. I’m perpetually glued to my screen, so I’ll usually answer if you find me. In the event I’m sleeping, there may be a delay.

Beginner’s Guide to Kadena: Accounts + Keysets was originally published in Kadena on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kadena began enabling Kadena (KDA) token transfers on December 17. The network has experienced some serious growth as we’ve transitioned from testnet to mainnet, with over 1,000,000 blocks mined by more than 10,000 GPUs (at an average hash rate between 10–15 TH/second) on mainnet. We’ve been heavily relying on the community to help establish best miner practices in the network.

Now, tokens earned by miners are transferrable to and from other accounts (peer-to-peer). Because transfers are such an integral part of any blockchain ecosystem, we’ve decided to publish this post as an introduction to the Pact smart contract system. We’d like to illustrate the myriad ways to transfer tokens and highlight some of the technologies available to users to do so. We’ll break down this tutorial into three steps of varying levels of sophistication: using Pact to create a smart contract, the standalone transfer portal, and transferring with the Chainweaver Wallet.

Hopefully, this will get you excited to begin your journey with Kadena. Let’s get started!

The Kadena Coin Contract

Kadena’s coin contract was made available as a transaction at genesis, which means the token is a contract in the same way that any other contract exists in the blockchain (though, it is somewhat special with the way each Chainweb node interoperates with it natively). While we don’t yet have a module explorer for people to browse module code (coming soon when smart contracts are turned on), you can browse the source and the Kadena Improvement Process (KIP-0002) RFC for the fungible asset token (KDA) on which it’s based to get a feel for both the Pact language and the fundamental operations available in the contract. Most notable among these are the specifications for how to transfer KDA to and from accounts on the blockchain. We’ll go through the accounts and the types of transfers available to you in the next few sections, and then move on to a tutorial for how to actually put transfers into practice along with some of the available tools.

How are Kadena Accounts Structured?

We’ve written up a Beginner’s Guide to Accounts in the Kadena blockchain, but let’s do a whirlwind tour here just to refresh. The Kadena blockchain is unique in the sense that each chain is a separate blockchain for which a global consensus is maintained, and there is no global notion of “account” or “address.” On each chain, however, there is a keyset registry that makes sure that no keyset gets duplicated. This means that the final decider for what uniquely identifies a user of the blockchain is their keyset on a given chain (read here for more on keysets). If you choose to have your keyset only exist on chain 0, that’s your prerogative and perfectly fine. However, users may find it simplifies things if they define their keyset on all chains to avoid confusion, even though there’s a cryptographically nil chance that anyone else might have the same keys on a different chain.

Every smart contract has the ability to maintain its own ledger (a key-value store) that defines the data structures it works with. In the case of the coin contract, every entry into the coin contract ledger is specified by an account name (any LATIN-1 string between 3 and 256 characters) as a key, with a value of both a decimal balance and a keyset that governs the account. Account names can be anything as long as they conform to that spec. You could be "emily", "stone cold steve", or simply the public key associated with your keyset as an account name. Many users find the latter to be the easiest to remember. Since the chance of overlap is negligible, it helps them remember which keys they’re supposed to use for that particular account. I support this, as the two accounts "emily" and "Emily" are distinct and it can be easy to forget which is yours. We call accounts that are not simply the public key string “vanity accounts” (like vanity license plates), to distinguish naming conventions.

So, to summarize,

key: Account name -> value: { Balance, Keys }

It’s that simple! Now, let’s talk about the types of transfers available with this token.

Types of Available Transfers

I’ve shown you how to construct a simple coin transfer, but now let’s talk about the types of transfers available to you, the user. The coin contract has 3 in total to address varying use-cases:

• coin.transfer: This function is for transfers between two existing accounts on the same chain, for some decimal number of tokens. This is the one I showcased above, and is the most basic of the transfers. It works exactly as you might imagine.
• coin.transfer-create: In the case where the recipient of the transfer perhaps does not exist, transfer-create is how you would transfer coins safely to the receiving account. If the recipient already exists, then coin.transfer-create works exactly as coin.transfer would with a single exception. You must know the keyset of the account you’re transferring to and provide it as a parameter to the function. When the receiving account exists, the keyset you’ve passed along is checked against the keyset on file for the account to make sure they’re the same for executing the transfer as expected. When the account does not exist, however, an account will be constructed using the recipient account and keyset with the balance transferred from the sender account. In general, this function is safer than coin.transfer, but that safety comes at the cost of convenience. I recommend using this one whenever possible.
• coin.transfer-crosschain: This function is especially interesting in that it is the only way to transfer tokens from one chain to another, and is a more involved process that requires you to learn about defpact continuations in Pact. I plan to cover this in a separate tutorial, where I have the opportunity to explain both defpact and Simple Payment Verification (SPV) in Pact and how cool it is (sorry Thanos!). In the meantime, just know that there is a way of transporting tokens across blockchains natively, available in Kadena (and Pact).

Smart Contracts with Pact

Pact is the smart contract language running at the heart of the Kadena public blockchain. We’ve produced a bunch of tutorials on every aspect of the Pact language ecosystem, but we’ll review a few here to illustrate our use-case. This will be done with Pact 3.3, the currently available version of Pact.

Creating an API request

Smart contracts are written in Pact. To actually get them into a block on the blockchain, they need to be sent to a blockchain node. This is done by formatting an API request and sending the request to the appropriate endpoint. Pact has this functionality built into the language in the form of the pact -a family of commands. To make use of pact -a, one must create an API request template that takes the form of a YAML script pointing at (or containing) Pact code, which is then converted into the appropriate JSON representation. A user may then submit this JSON in a cURL request (or e.g., a Postman request) to the blockchain for processing.

For example, if I wanted to transfer 1.0 KDA from my vanity account, emily to nick-cage because I’m such a huge fan, I would construct a YAML template request like the following (note: using a burner keypair generated by pact -g for demonstrative purposes):

This looks complicated. Unfortunately, it is, which is why we automate this all in the wallet. All you have to do is toggle the knobs with whatever is appropriate. However, it’s still good to know about what settings you’re able to toggle to achieve an optimal transaction specification. The anatomy of this request can be broken down as follows:

• (code|codeFile): This field is either the raw code you wish to execute or a reference to a .pact file containing the smart contract you wish to execute.
• publicMeta: This field contains all of the blockchain-specific metadata needed to interact with the Kadena public blockchain. It speaks for itself. A user must specify how much gas they’re willing to pay and at what price, where they’re sending it, who the sender is, etc. The creation time and TTL define what period of time your transaction can be submitted to the blockchain. The creation time is the time that your transaction can first be submitted (specified as the number of seconds since 1970 — i.e. since POSIX epoch) and the TTL (time to live) is how many seconds it will be valid for before being removed from the mempool. In practice, you can also go to duckduckgo.com and search for ‘unix epoch’ to get the current time, but I’ll usually just go into Node.js and run the following:

Math.round((new Date).getTime()/1000)-15;

• networkId: This field describes the ID of the receiving network. Since Pact is blockchain-agnostic, this may be Tendermint, or Polkadot, or any of the myriad blockchains supported or to be supported in the future. Currently, the network ID for the main Kadena network ismainnet01, but through this tutorial, I’ll be running on testnet04 to make sure no actual transactions go into the main blockchain.
• keyPairs: The public/private fields are self-explanatory — you have to sign the transaction somehow. The less obvious field is for capabilities allowed in the transaction. Capabilities are an integral part of the Pact security model. If a particular smart contract supports capabilities, then you’re allowed to say exactly what operations you (the signer) allow for use of your keys. In the case of the Kadena coin contract, we’re allowing my keypair to be used for gas payments, as well as a transfer of a specific amount. These operations can be automated and brought into scope by contract control flow, but the coin contract requires your feedback for safety reasons.
• type: This will only ever be exec for one-off scripts, or cont for escrow continuations. In our case, we’re executing a one-off transaction.

For a more complete specification of the available options, consult the Pact API Request Formatter documentation and the tutorials on pact-lang.org. Here’s a template that can be copied and pasted for your requests:

code:
data:
networkId:
publicMeta:
  chainId:
  sender:
  gasLimit:
  gasPrice:
  ttl:
  creationTime:
keyPairs:
  - public:
    secret:
    caps: 
type: exec

And here’s the one I used that you can cargo cult for yourself and change all of the bracketed fields:

code: |-
  (coin.transfer <from> <to> 1.0)
publicMeta:
  chainId: "0"
  sender: <from>
  gasLimit: 600
  gasPrice: 0.0000001
  ttl: 600
  creationTime: <regenerate this>
networkId: "mainnet01"
keyPairs:
  - public: <public>
    secret: <secret>
    caps:
      - name: "coin.TRANSFER"
        args: [<from>, <to>, 1.0]
      - name: "coin.GAS"
        args: []
type: exec

Once I have this YAML file all figured out, I generate the following JSON request using pact -a and passing in the YAML file as a parameter:

Now, I have a JSON object that I can post to the /send endpoint of the Pact Service API for the Kadena blockchain. In practice, this will be a POST request with the formatted JSON object on a node endpoint which takes the following form: https://<host>:<port>/chainweb/0.0/<network-id>/chain/<chain id>/pact/api/v1/send. Here is an example cURL request that I’m using:

curl --location --request POST 'https://us2.testnet.chainweb.com/chainweb/0.0/testnet04/chain/0/pact/api/v1/send' \
--header 'Content-Type: application/json' \
--data-raw '{"cmds":[{"hash":"F7jzCyUgwcBUWYVe3xEFw66X45NHgheNrqm8LL9gMIU","sigs":[{"sig":"c0024309593b8b28b356c5edfed957c1dd7e163eecc446a327fa8d4db76faccc111b11786fe9cc6fc200ceab137d53f4df46ab76aa7f268be183289f282db20e"}],"cmd":"{\"networkId\":\"testnet04\",\"payload\":{\"exec\":{\"data\":null,\"code\":\"(coin.transfer\\n  \\\"emily\\\"\\n  \\\"nick-cage\\\"\\n  1.0)\"}},\"signers\":[{\"pubKey\":\"368059ab25bec92f19a4f8ce172030e5d672e4879aaae8d5be8b705dd3dfae7f\",\"clist\":[{\"args\":[\"emily\",\"nick-cage\",1],\"name\":\"coin.TRANSFER\"}]}],\"meta\":{\"creationTime\":1576691834,\"ttl\":600,\"gasLimit\":100000,\"chainId\":\"0\",\"gasPrice\":1.0e-7,\"sender\":\"emily\"},\"nonce\":\"2019-12-18 17:58:40.212918 UTC\"}"}]}'

When the blockchain has accepted your request, you’ll get a request key back — the unique key associated with your request as it’s processing.

To see the outputs of your transaction, POST that request key JSON object to the /poll or /listen endpoints. When the transaction has been mined and exists in some block, you’ll get a response back. Note that it may take a few block heights (i.e. 30–90 seconds) to see your transaction, and you will not receive outputs during that time. Here’s an example of a /poll cURL request and the response:

curl --location --request POST 'https://us2.testnet.chainweb.com/chainweb/0.0/testnet04/chain/0/pact/api/v1/poll' \
--header 'Content-Type: application/json' \
--data-raw '{
    "requestKeys": [
        "BYHjcdTqqMTROLasn82ka-DpYhE9Q1K3nFxt5vcXxGQ"
    ]
}'

Success!

We realize that this is a low-level technically intensive process, but like every API on the web, there exist tools that automate this experience and provide varying levels of sophisticated UI to help make the process seamless. We’ll get into these tools below, but first, let’s talk about dry-running transactions to make sure that they succeed.

Using /Local to Dry-Run Transactions

The Kadena blockchain follows the example that Ethereum set by charging the gas limit specified in a transaction in the case that the transaction fails. This takes place for a few very important reasons:

• It incentivizes users to only submit transactions they know will succeed, or get penalized. This closes a serious DOS vector for node operators.
• Miners are compensated for computational costs of failing transactions, which may fail for a variety of nondeterministic reasons, such as database datasets exploding in size to the point that transactions can’t cover them.
• To a lesser extent, it incentivizes automation and “safe” modes of transaction, such as wallet or script use that contribute toward a robust ecosystem.

On its own, this would be a rather punishing system. After all, it is inevitable that new users will be unfamiliar with how to transact with the blockchain. And even more so inevitable that people make mistakes when transacting. To provide as much information as possible, every Kadena node has a dedicated endpoint called /local on which a user can dry-run their transactions and discover the costs and outputs of a given transaction.

As mentioned above, pact -a is a family of commands. The command that generates a valid local request is pact -l -a, and can be used with any existing request YAML to produce a JSON object compatible with the /local endpoint of any node. Chain ID does not matter in this case — the endpoint will accept any valid command — but it’s good to provide accurate information to produce valid feedback for the dry run. As above, we’ll reuse the existing transfer request from "emily" to "nick-cage":

Now, let’s submit this to pact -l -a. This will generate the following JSON object:

Then, let’s send this to the /local endpoint. This time, rather than receiving a request key, we receive the outputs directly along with some additional metadata not included with the outputs of a /send transaction:

The outputs display the results, the logs, a request key, all of the metadata used in the transaction, along with the most up-to-date block time, parent block hash, and block height on that chain. Not only do you know if your transaction will succeed, but you’ll have all the context you need to figure out why it failed. Let’s see what failure looks like in this mode by using a user that does not exist as the recipient of our transfer:

Our recipient, “Lol I am definitely not Nick Cage,” does not exist in the blockchain, and so I’ve received confirmation that my transaction failed. This information is sent along with the callstack, type of error, specific failure message, and wherein the coin contract the code that called it failed.

Tools for Transfers

As mentioned above, there are a few tools available to you that automate the construction of API requests (and transfers in particular). They are available in a few different forms.

Community Transfer Scripts

There is a standalone community transfer script which automates the construction of transfers by providing web fields which fill in the necessary information for your API request and call our Pact Lang Javascript API which sends the transactions for you:

You can either set this up in your browser by using the index.html provided, or you can run it as a standalone script with node as described in the README.md of the project. If you read the first section thoroughly, it should all be very familiar, and you can picture how the YAML is being created and sent via this information. However, you’ll see that there’s a lack of gas and TTL/creationTime. That is because we’ve chosen some sensible defaults that should make the process even easier. This script will run a coin.transfer or coin.transfer-create depending on the parameters you supply. Pool operators and power miners such as BigShoots have set this up on their nodes as a courtesy to other users (thanks BigShoots).

Chainweaver Wallet

If you’re on Mac or Linux, you can make use of Kadena’s in-house Smart Wallet offering: the Chainweaver Wallet.

The Chainweaver Wallet features a full Pact IDE (including a REPL) for authoring smart contracts and interacting with existing smart contracts on the Kadena blockchain in addition to its account servicing features. I recommend you run the wallet from the perspective of a smart contract writer (and, for transparency, a Kadena employee).

Chainweaver has a great UI for sending and receiving tokens using a novel address format for Chainweaver users that we are calling a Kadena Address. In the Wallets tab, locate your Chainweaver account and simply click the “send” tab, which will take you into a small popup window in which you can paste the Kadena Address of the receiving account. Depending on the context, Chainweaver can detect whether a particular receiving account exists and on what chain, and will choose whether to use coin.transfer, coin.transfer-create, or coin.transfer-crosschain depending on that context. It will even automate the previously manual step of constructing an SPV proof in the case of a cross-chain transfer. We’ve written up a thorough tutorial to help you understand all of the snazzy features available in Chainweaver.

Additional Wallet Options

We welcome any wallet additions as community projects and will be happy to help set you up with a dedicated repository in our Kadena Community GitHub organization if you have a submission. There is one already, courtesy of our Kadena’s Colin Woodbury (@fosskers). He wrote a fantastic CLI wallet aptly named Bag of Holding, which you can operate from your terminal:

Bag of Holding works essentially as a nice UI around the creation and execution of API requests as described earlier in this article. It’s solid, simple, reliable, and (I think) looks great.

Conclusion

There you have it: an introduction to Pact transactions by way of transfers. Our tooling is in the very early stages. We welcome help from the community for documenting these tools and constructing new ones along the way. We are always happy to rep community-blessed tools if they are better than our own. We welcome anyone to contribute to the Kadena Community projects repository with your own project or add to existing ones. So far, the community projects have yielded both a great terminal wallet with Bag of Holding, and a blazing fast GPU miner courtesy of Alex Khonovalov, Edmund Noble and myriad other insanely smart community members.

Thanks to everyone who contributed, and please feel free to raise your questions to me in Discord — my handle is one of @topos, @pitopos, or @emilypi depending on where I am on the internet. I’m perpetually glued to my screen, so I’ll usually answer if you find me. In the event I’m sleeping, there may be a delay.

Glossary

• Keyset: Refers to the Pact Keyset authorization scheme. These are a set of public keys in addition to a predicate function (e.g. keys-all, keys-any etc.) that decides the authorization policy for the keys in the keyset. For example, if I have a set of keys with the keys-all predicate, then all keys must be present as signers in a transaction to do anything with the keyset.
• Account: An entry in the Kadena coin contract ledger (a key-value store). This consists of a string of 3 to 256 LATIN-1 characters as a key, pointing at a value consisting of a decimal balance and a keyset governing the account.
• Vanity Account: We call accounts “vanity” accounts when they have a custom vanity name that is not just the public key string associated with a keyset. Think of it like a vanity license plate.
• Token (KDA): When we refer to “the” token, we refer to the definition and implementation of the Kadena fungible asset specification, called fungible-v1 and coin, respectively. In practice, this just means the coin contract!
• Smart Contract: Pact modules define smart contracts.
• API Request: An HTTP request sent to one of the endpoints available on any Kadena Blockchain Node.
• Transaction: An API Request sent to the /send or /local endpoints of a node, which executes Pact code. Sending an API request to the /send endpoint results in a transaction that gets included in a block, while a request to /local will not.
• Capability: This refers to the capability permissions system baked into the Pact language. More on this to come.
• Dry-run: A transaction sent to the /local endpoint.
• Gas: How many units of compute (i.e. tokens) it takes to run a transaction
• Gas Limit: How much gas is available for the transaction, specified by the user.
• Gas Price: The price of gas that the user is willing to pay. This is a decimal multiplier for the gas limit, which results in the final gas supply available for a transaction. The result is measured against how much gas it takes to run a transaction to determine the miner reward, and any refunds the user might receive (i.e. total gas supply minus total gas used).
• Chain Id: The identifier for a given chain in the Kadena blockchain. (Currently, they are 0 through 9).
• Creation Time: Time in seconds since POSIX epoch (i.e. since 01/01/1970:00:00:00) that marks the earliest time that a transaction should be considered a candidate to be included in a block.
• TTL: Time-to-Live — the expiration date in seconds for how long a transaction should be considered for candidacy in a block after its creation time. TTLs can be at most 48 hours after the initial creation.
• Network Id: The unique identifier for the network (e.g. testnet04 or mainnet01)
• KeyPair: A public/private keypair.
• Public Metadata: The non-transactional data of a Transaction used to interact with the blockchain (i.e. what chain ID, TTL, creationTime, who the sender is, etc.)
• Blockchain Node: A Kadena node
• Wallet: A device, physical medium, program or service which stores the public and/or private keys. It can be used to track ownership, receive, or spend cryptocurrencies.
• Kadena Address: The unique, secure format in which the Chainweaver Wallet stores accounts.
• IDE: Integrated development environment
• REPL: Read-eval-print-loop. Many languages have this as a means of getting fast feedback and running code.

Kadena Public Blockchain: Getting Started with Transfers was originally published in Kadena on Medium, where people are continuing the conversation by highlighting and responding to this story.

After a lot of hard work by the team at Kadena, we are pleased to announce the release of Pact 3.1! This new version of Pact brings significant additions to the language, including expanded Formal Verification coverage for our interfaces and governance, and our new cross-chain features in defpact, which makes it dead simple to write cross-chain multi-step transactions.

These features continue to reinforce Pact as the premier standard for smart contract authoring in both public and private blockchains. You can try the latest version of Pact out by downloading from our Github.

Formal Verification

Pact 3.1 pioneers new features that make the more complex parts of writing smart contracts as easy as possible. Along with these features, we’ve continued expanding our Formal Verification coverage.

Pact Interfaces

Interfaces were introduced into Pact in 3.0 as a way to allow users greater flexibility when layering behaviors in module code. These constructs act similarly to the interfaces in Java, or traits in Rust and Scala, with one big difference. In Pact 3.1, users can now write Formal Verification properties and even define their own custom models in the bodies of interfaces and their function signatures!

When a module implements an interface containing these properties, those properties are inherited by the module. If a module implements more than one interface, every interface’s properties are imported together, to provide the module with that much extra security. This allows users to write the specifications and laws for a module. Interfaces can thus provide robust hierarchies of safe, secure, and reusable smart contract behaviors with the help of Formal Verification. You can read more about interfaces and see example code here.

Verified Governance

For the Pact 3.0 release, we debuted an exciting new set of features in Pact: guards and capabilities. These primitives allow you to create robust and flexible security metaphors as a native feature of the language. With Pact 3.1, we are proud to announce that we have Formal Verification analysis for guards and capabilities, allowing you to not just write secure and flexible code, but prove that it is secure and flexible code.

When writing formal verification properties for a function, users can combine a security predicate for a guard or capability such as(authorized-by ‘my-keyset)with the new governance-passes property to enforce their requirements. You can even analyze governance over database operations guarded by security protocol.

Defpact step signatures

One of the killer features in Pact is its ability to support generalized, multi-step transactions (e.g. escrow transactions) built directly into the core of the language via the defpactconstruct. Formal Verification in Pact now allows you to specify properties for each step in a defpact so that users can make each step sound and secure.

This is just one aspect of some of the updates we’ve made to defpacts this release. On top of this, we’ve added an incredible new feature: cross-chain transactions.

Cross-chain Multi-step Transactions

One of the boldest new features in this version of Pact comes as part of our ongoing work on the testnet for our public blockchain.

Blockchains like Bitcoin and Ethereum are traditionally single-chain, so their currencies naturally live on one chain. But what happens when you have a whole bunch of chains working in consensus, like in our Chainweb protocol? A currency is defined on a per-chain basis, so there would be as many currencies in the network as there would be chains. However, at Kadena, we have solved the problem of unifying disparate currencies in a multi-chain network with the power of two pre-existing standards in both Pact and the blockchain ecosystem: simple payment verification (SPV) and multi-step defpact transactions.

The Kadena coin contract allows users to transfer any number of tokens from an account on one chain to an account on another chain using the power of SPV. In fact, it looks the same as your standard single-chain transfer, except now users can specify an extra parameter: the target chain to which they want their tokens sent.

Defpacts already had yieldand resume to securely forward data between steps. As of Pact 3.1, cross-chain transactions are as simple as specifying a target chain you’d like to yield some data to in the following step. For a user to perform the second step on the target chain, they simply provide the correct SPV proof data as part of a continuation request, and theresume call in that step will perform the proof and retrieve the data automatically.

Coin transfers are a simple example of the more general concept of cross-chain multi-step transactions: the ability to execute multi-step transactions, of which each step can occur on a different chain. Pact now supports this by default!

Conclusion

To learn more about writing safe smart contracts in Pact, visit our educational resources:

• PactLang.org — find videos, tutorials, and example code.
• Try Pact — start exploring Pact (3.0) in your browser, no downloads necessary!
• Beta test smart contracts — get in touch with the team via Discord if you want to participate in our public blockchain testnet.
• AWS Marketplace — take our private blockchain for a (free) spin and try out some of these cool new features for yourself.

Pact 3.1 is Unleashed! was originally published in Kadena on Medium, where people are continuing the conversation by highlighting and responding to this story.