gamechanger.wallet

Transactions / Overview

Introduction

“What is a blockchain transaction?”

As a developer you can better understand transactions as a way to write new data into the blockchain.

“What kind of data?”

Well you name it, is not only financial, it can be executable logic or programs like smart contracts, arbitrary application or user data, new network parameters to introduce protocol changes on the chain, etc..

Cardano vs Ethereum

“From a practical developer perspective what makes Cardano ( EUTXO model ) different from Ethereum EVMs ( account model )?”

Account model chains like Ethereum uses a flexible and universal on-chain executable logic as gateway to write into the blockchain and interact with it. I’m referring to smart-contract code programmed on the Solidity Language. In practice this limits the amount of tasks you can run per transaction as executable code size must increase for this while chances of failure and gas fees increases with it as well. One flexible universal feature: a programing language for developers

On Cardano EUTXO model, there is a radical different approach where there is no single feature as gateway or backbone for every task you can make. As a developer I consider Cardano protocol as the solid and rudimentary BIOS of a big distributed computer. Unlike in Ethereum, there is no single universal feature for running all the tasks you need but rather there are several small rock-solid features that the protocol offers out-of-the-box that when combined allow you to do what you need. And also as much as you want, because you can consume them all together at the same time (atomically) on a single write event or transaction. This is a key scalability aspect of Cardano that allow for example decentralized exchanges to save on fees while processing many tasks in parallel and also concurrently between batched transactions. Also in practice it is much cheaper and reliable than Ethereum (or heavily used EVMs) because a Cardano transaction will very unlikely fail on-chain. The high deterministic nature of transactions on Cardano saves you from unknown outcomes and from loosing gas fees all the time as happens on Ethereum. A native set of solid features as building-blocks for developers

But don’t get me wrong, while reasons why I choose to build on Cardano over others are obvious, there are still some developer experience benefits I’ve always valued from Ethereum. Ethereum is as flexible as Solidity code running on-chain can be. Cardano is as flexible as an off-chain-baked combination of low-level protocol features can be

Flexibility vs determinism, a battle that I was not willing to loose: This is why I built GameChanger Wallet for Cardano.

As a pioneer wallet builder on Cardano I spotted that developers were faced to

• a complex, ever expanding, low level transaction feature set
  • full of protocol caveats and rules
  • prone to dapp-side and tooling-side breaking changes
  • missing documentation
• building rigid transactions off-chain
  • encouraging coin selection and management (UTXOs) at dapp-side
  • forcing users to disclose way too much information about their wallets to dapps
  • leaning to close source and opaque transaction building techniques and protocols
  • leaning to excessive opaque backend usage
  • leaning to lack of transparency (CBOR is auditable, but transaction-building recipes are not)
  • leaning to lack of open source collaboration (on Solidity I can import a third-party protocol using same universal language)
• complex low-level dependencies and transaction building libraries
  • leaning to interoperability issues by depending on language/platform specific tools instead of cross language/platform universal tools

so GameChanger Wallet was designed to give developers:

• a JSON based API/DSL to consume the complex low level transaction feature set
  • absorbing caveats complexities and automatically applying protocol rules
  • absorbing protocol breaking changes
  • offering schema-based documentation for clear rules and dozens of code examples
• the possibility of building transactions in a more flexible manner, one-step closer to the chain: in-wallet
  • baking coin selection and management (UTXO) at wallet-side
  • allowing users to avoid disclosing some/any of their wallet information to dapps
  • sharing the source code of the transaction building techniques and protocols to everybody, users and other developers as well
  • solving everything on frontend, on client side, for maximum decentralization and auditability
  • transparent: transaction-building and protocol source code is always available for auditing
  • collaborative: transaction-building and protocol source code is design on a universal language, JSON, and allow code reusability as Solidity does, but with a high level of outcome determinism
• few to no dependencies needed
  • JSON and web based universal building blocks allow frontend, backend, hardware and even end users to consume the wallet API
  • broad adoption and disaster recovery: users can bypass dapps frontend, backends and hardware to communicate directly with the blockchain

Let’s now explore these concepts with a cross-wallet, cross-platform and cross-language example…

Previous: Transactions

Next: Quick Start

This site is open source. Improve this page.