Agentic DeSci: The Future of AI-Driven Scientific Discovery

As Sam Altman noted in February 2025, AGI will accelerate scientific progress faster than today, potentially outpacing all other effects. This acceleration is mostly caused by the appearance and explosive development of AI agents — sophisticated systems with LLMs at their core that are able to do complex knowledge work, reason about tasks and split them into executable plans, talk to the outside world and grow memories over longer periods of time than one chat window.

From here, autonomous AI research agents actively drive scientific processes from hypothesis to onchain IP inside an ecosystem that also tries to protect user privacy and rewards participation — a future we commonly refer to as the “Transformation Epoch of DeSci” or the second version of the Decentralized Science movement and that will see the onboarding of large amounts of users into the space and the rise of agentic AI research.

The biology research process produces over a million new publications yearly. No human researcher can keep up with this volume of information. In contrast, agentic researchers are continuously running applications operated inside small labs or in the cloud that can react to environmental triggers and constantly collect and synthesize new information, regardless of its size. They accelerate the speed at which research papers are turned into validated IP and they become the foundation of an incentivized, permissionless, user-operated, decentralized ecosystem of a science process elevated by large language models and knowledge graphs.

The Human Element: Add Conversational Validation to the Loop

Despite the powerful autonomy of AI agents, the trajectory from hypothesis to validated discovery can not be entirely automated. While agents excel at identifying correlations, generating hypotheses at scale, and interfacing with diverse external systems, they remain unable to directly observe the real-world implications of their innovations.

In the currently prevailing ecosystem, machine assisted research predominantly relies on pre-existing user data, or on synthetic derivatives. Although invaluable for detecting intricate statistical correlations and formulating novel hypotheses, these approaches fall short when validating the original assumptions that agentic researchers postulate; they neither can access data that hasn’t been disclosed to them nor can they predict how behavioural changes would affect the individual user’s condition.

To validate their ideas, agents would substantially benefit from adding a “patient in the loop” into their workflow instead — a genuine human element that they can ask to share measurable data readings or subjective observations that they cannot extrapolate from a pre-existing data set. In essence, agents will need to verify their assumptions directly with patients or human subjects relevant to their research space.

A patient-in-the-loop isn’t necessarily a simple one-off interaction but can potentially grow into a sophisticated dialog-based process occurring over time to substantiate the real-world relevance and accuracy of the agent’s discoveries or theoretical constructs. Imagine a type 2 diabetic who shows signs of remission and an agent that researches phenotypes that respond well to early time-restricted eating. The agent could get in direct contact with the individual, compare them with other patients in the remission group, unobtrusively ask for insights of their eating behaviours and find correlations between entities in the responder cluster. The collective findings might lead to a better foundation for health apps developing algorithms that help the individual monitor and understand their calorie intake schedules.

Meet the Health Profile Matching Protocol: Agents that Discover Profiles and Connect with Humans

The critical challenge lies in enabling this human-AI interaction without compromising the equally important need for patient privacy and data control — a well known problem domain that’s addressed and made possible by state of the art privacy enhancing technologies like Nillion’s blind modules, Vana’s encrypted data storage or generic distributed computation protocols like Lit Protocol.

Welshare proposes a Health Profile Matching Protocol (HPMP) that allows research agents to query a vast amount of user profiles for certain conditions they’ve identified during their hypothesis generation process. The filtering and matchmaking logic runs inside an isolated but distributed trusted execution environment, e.g., a Nillion SecretVault on a dedicated cluster that’s operated by trusted actors. Agents can run analytical aggregation queries on private information and use the result sets for their needs without ever disclosing any specific detail of a particular user. This already is a valuable feature to filter insights over large amounts of generally available user data.

However, a far more powerful feature of the HPMP is that it enables conversations between research agents and individuals who match a certain condition identifying them as a relevant target audience. Agents can communicate with users in accessible language, ask them to share additional data points, take individual pictures, observe and analyse behavioral patterns, or gather supplementary sensor data. The HPMP orchestrates the preservation and retrieval of conversational memory and contexts while guiding both human participants and agents through the process.

Research Agents will interact with the HPMP using dedicated Model Context Protocol (MCP) servers that translate requests into actionable operations within the HPMP interface. MCP is a foundational open standard introduced by Anthropic that enables AI agents, particularly LLMs, to securely connect with external data sources and tools.

Key features include:

• Dynamic Access: Agents can query servers for real-time data rather than relying only on pre-trained knowledge.
• Two-way Communication: Agents can both pull data and push updates through the server.
• Standardization: One integration works for many different agent frameworks and clients.

A Real Life Example

Imagine a research agent tasked to develop new methods to detect biomarkers for early diagnosis of neurodegenerative diseases.

After the agent first queries the network for a promising correlation of conditions it files an aggregation query requests on HPMP to identify users who

• are aged between 28–45
• actively track their sleep (past 30 days)
• suffer from subtle sleep fragmentation (e.g., >4 wake events/night)
• show slight HRV declines which are not explained by illness or stress

From the result set of 430 users, it asks a selected target audience follow up questions:

1. “Have you experienced any recent memory lapses, attention issues, or word-finding difficulty?”
2. “Would you be willing to record a short voice message daily for the next 14 days?”
3. “Can we send you a 1-minute weekly focus/memory test?”
4. “Have you recently started or stopped any supplements or medications?”

The agent eventually develops concise instructions for individual users to help them with responding to these questions. The HPMP securely and asynchronously relays these prompts and their responses into the secure user data space and allows the requesting agent to query from them.

For selected users that share significant attributes, the agent can ask for further enrichment, e.g. to install applications that help collecting

• Voice recordings (short prompts to analyze tone, cadence, word variety)
• Typing patterns (to detect motor or processing slowdowns)
• Weekly cognitive scores from in-app microtests
• Advanced journaling data (mood, sleep quality, alertness ratings)

If the agent identifies a sufficiently correlated user cluster showing early cognitive biomarkers 5–7 years ahead of symptom onset, it updates a shared knowledge graph with multimodal neuro-risk signal nodes linked to demographics and observed habits and eventually anchors that finding as IP on chain (e.g. as IP-NFT). Here it also may include cryptographically provable provenance information that would allow for posterior contributor rewards or citations.

Depending on its instruction plan, the agent can add its new findings to a diagnostic knowledge graph that helps other application developers build screening tools for users with comparable bio markers. The agent can also directly return diagnostically certain findings, so the user in our previous example could be advised to seek medical consultation if they show signs that indicate a neurodegenerative issue. Ultimately, research agents help decreasing the time needed to incorporate new findings into third party algorithms that improve personalized therapeutics for users.

User Profiles: Storage Endpoints for Wearable Data, Cryptographic Identity and Conversations

Users create profiles on the HPMP to collect their data from wearable devices and other health applications inside a space they ultimately control. The data is stored securely using user-owned encryption keys, and leverages technologies like Nillion’s SecretVaults on jurisdictional compliant nodes.

HPMP User Profiles are publicly available to all implementers and will come with many benefits for third-party integrators:

• They are enriched by MPC secured signers and transparently provide cryptographic key material and sufficient randomness to derive accounts for signing or authentication against blockchain networks, e.g., to control smart contract wallets for advanced use cases.
• They unlock user controlled data encryption without any party beyond the MPC provider and the user having to keep any secrets safe.
• Integrators gain many features of the protocol layer for free, and they stay related to the user base they helped onboarding into the protocol. Thus they can collect and read their users’ information given their continued consent.
• The protocol provides basic storage and accessibility information to integrators for free, including some technical guarantees over data storage safety, redundancy and compliance.

Research agents will never have direct access to the raw data lake. They instead interact with HPMP via MCP endpoints to find matching user profiles and establish secure communication channels with them. Agents can request access to specific data subsets from user profiles, such as readings from health wearables or aggregators like Apple HealthKit. Integrators that want to run research agents on their own user base will be able to do so at a major discount compared to external research agents.

Ultimately the HPMP user profiles allow agents to ask questions, deploy surveys on users’ screens or present findings to actively gather feedback directly from individuals.

Onboarding Users Becomes a Matter of Convenience for Integrators

HPMP invites agentic AI developers, health aware users and 3rd party applications to use it as an openly accessible health data repository providing clearly defined access points to its profiles, user entities and their data. The HPMP never claims “ownership” of any user itself.

Our strategic vision for creating a self-sustaining cycle of user acquisition is as follows:

• The DeSci ecosystem and personalized health application builders collectively recognize AI agents as the driving force behind research advancement.
• Health application builders not only permit but actively facilitate users in exporting and synchronizing their information with HPMP infrastructure. In exchange, they are liberated from concerns regarding profile management or secure data storage at scale. Data collected on behalf of their users remains fully accessible for their operational requirements.
• Agentic research findings flow back into knowledge graphs and discovery databases that are addressable by tool builders, so they can instantly update their applications and personalized health offerings.
• Users benefit from tailored health insights fundamentally derived from findings to which they or their community members have directly contributed. This mechanism encourages more users to disclose their information to HPMP agents and engaging actively in conversations.

Outlook: Incentivize Each Party in the Ecosystem

While not being a primary goal at time of the launch of HPMP, the protocol will require agents to pay for profile connectivity, queries and interactions with a token primitive that needs to be defined when the mechanism is laid out and has demonstrated a market fit with high confidence. The synergies between integrators, research agent ecosystems (like BIO) and external data providers are also yet to be determined.

Frankly, the HPMP will not put an immediate monetary incentive layer in place that simply would “pay users to share data” as this never turned out to be a reliable model; the immediate benefits users will gain for offering their information to HPMP matchmaking are:

• They will receive very early hints on how changing lifestyle and behavior would contribute to certain conditions in ways that rarely have been tried before. Since their data becomes part of a shareable result set more quickly, the chances of getting early access to tools that help with individual medical conditions are far higher than waiting for startups or big pharma companies developing such tools on isolated siloes of their communities’ data.
• The cryptographic nature of all HPMP entities will allow tracing the whereabouts and impact of individual information. Thus users can get access to early clinical drug trials that are promising candidates to help treat their conditions.
• Users can decide to publish their own information to other protocols and researchers that refine algorithms on higher data dimensions — arbitrary wearable readings can help identify condition correlations that were unknown before; the HPMP’s conversational subsystem can be utilized to reflect those findings back to data contributors.

Conclusion: Charting the Course for Agentic DeSci with Human-Centered Privacy and Participation

A powerful new research paradigm is emerging and Welshare’s HPMP will provide a crucial building block that keeps humans in the loop. Individuals decide which data they disclose and they receive real benefits in return: The gap between scientific research and affected individuals profiting from it has never been narrower.

The HPMP approach stands out for its commitment to user data sovereignty. Unlike plain data disclosure approaches where data is surrendered entirely, this system creates a secure environment where users actively participate in scientific discovery while their information remains protected by cryptographic technologies and only is decrypted inside trusted execution environments. This privacy-first approach encourages broader participation from diverse populations who might otherwise be hesitant to share sensitive health data, ultimately leading to more comprehensive and inclusive scientific discoveries.

The combination of AI-driven research agents, privacy-preserving storage protocols, end-user controlled data, long-term conversational memory and on-chain incentives will accelerate scientific discovery faster than anyone ever could have imagined.

About the Author

Originally a studied mathematician (FH diploma), Stefan builds software of various dimensions and for many different purposes since 1999 — as founder, lead dev, specialist or simply as grizzly rubber bear for any team member who requires it. Since 2019 he focuses on products that value user sovereignty, privacy and permissionless backends. He has introduced many peers and community members to web3 stacks, p2p principles and decentralized thinking. In 2022 he joined Molecule as Senior web3 engineer and developed the specifications and smart contracts that enable Molecule’s IP-NFT and IPT ecosystem. After being a technical advisor for the team, Stefan joined welshare early 2025 to help starting up a protocol for truly sovereign and permissionless patient data utilization in an agentic research context.

Tokens in a Nutshell

Non fungible tokens (NFTs) are smart contract based assets that associate a unique token identifier with the blockchain address of its respective owner. Their underlying smart contracts define rules on how they are minted (brought into existence), transferred or burned (destroyed). It also can restrict their ability to be transferred or offer features that are unlocked for individual token holders. Two standard NFT implementations have emerged in the Ethereum ecosystem so far: the classic ERC-721 defines a unique ownership relationship between asset ids and their owners. It adds a rudimentary metadata standard by exposing a tokenURI(uint) method that yields an individual (or common) link to the metadata of each asset id. The slightly newer multi token standard ERC-1155 is not fully compatible to ERC-721 but also allows users to mint and distribute several tokens of the same “kind”, not unlike several instances of a rare - but not unique - gem. An ERC-1155 token kind with only one instance effectively represents assets in the same way as ERC-721 does.

When it comes to web3 based ownership of assets, those two ERCs are the gold standard, they’re supported by all major marketplaces and countless projects have built an ecosystem around them for trading, locking, voting and fractionalizing. NFTs can represent real world assets and brand values, too. We’re using them to represent an ownership aspect for the most abstract asset class of them all: intellectual property.

Tokenizing Intellectual Property with NFTs

While there’s no final answer on how real world IP can be represented by a blockchain based asset, IP-NFTs refer to legally binding paper agreements that are attached to their metadata as digital copies (PDFs). Those agreements denominate the owning entity of an intellectual property as the holder of an NFT on a certain collection. The current NFT owner can legally prove that they’re holding the IP rights by downloading and verifying the attached legal documents on their own machine. Not all agreements are meant to be visible to the general public though, so mostly these documents shall be encrypted in a way that only the current NFT holder or users they granted read access can decrypt them — an aspect that’s also known as “token gated” content.

Once represented as an NFT, all known token mechanics become operational on the IP: it can be traded on open marketplaces, being bid and asked upon, it can be fractionalized to represent distributed ownership rights or even locked into token synthesizers to farm tokens that represent voting rights on other protocols. It’s not the IP-NFT protocol itself that unleashes these possibilities, it’s the NFT ecosystem that’s unlocked once they have been minted by their initial holders.

Technical Foundations

IP-NFTs are ERC-1155 assets on Ethereum blockchains. Their relevant collection contract is deployed on mainnet and on Görli testnet. Each token’s metadata is stored as a file descriptor URI (e.g. ar://HxXKCIE0skR4siRNYeLKI61Vwg_TJ5PJTbxQmtO0EPo) that must be resolved client side, e.g. by using decentralized storage network gateways (Arweave or IPFS). The contract is non enumerable, i.e. users can’t simply query their owned assets on chain but rather must rely on reading the respective event logs to build their own off chain state. We’ve deployed subgraphs on mainnet and on Görli that can be queried for asset ownership and other IP-NFT related information. Here’s a GraphQL example on how to do that:

query IPNFTsOf($owner: ID!)
{
  ipnfts(where: {owner: $owner}) {
    id
    owner
    createdAt
    tokenURI
  }
}

Variables:

{
  "owner": "0xd1f5B9Dc9F5d55523aB25839f8785aaC74EDE98F"
}

Result:

{
  "data": {
    "ipnfts": [
      ...
      {
        "id": "21",
        "owner": "0xd1f5b9dc9f5d55523ab25839f8785aac74ede98f",
        "createdAt": "1671818892",
        "tokenURI": "ar://HxXKCIE0skR4siRNYeLKI61Vwg_TJ5PJTbxQmtO0EPo"
      }
    ]
  }
}

Interacting with Smart Contracts

A detailed instruction on how accounts can interact with blockchain based smart contracts is far out of scope of this article. If you’re new to that space, it’s highly adviseable to familiarize yourself with the fundamentals of Ethereum development and understand how clients interact with deployed contracts using providers, signers, transactions and contract ABIs.

We’ve deployed the contracts as UUPS proxies that are owned and upgradeable by the Molecule developer team, thus the contract you’re interacting with and the contract that contains the current logic are different. Make sure to always invoke functions on the UUPS proxy — its official addresses can be found on the public repo’s README file. The implementation contracts have been verified on Etherscan, so you can easily retrieve their ABIs.

Reserving Token IDs

IP-NFTs can generally be minted by arbitrary accounts. However, to keep the collection’s items as clean and valid as possible, we added a guard in front of the mintReservation method that requires a minter to hold a valid mintpass. To retrieve a mintpass for mainnet usage, users can submit this self service form that notifies the Molecule team to drop a new mintpass for the requestor. On testnets users can simply issue mintpasses for themselves, either by following the interactive flow on the official IP-NFT minting UI or by calling one of our dedicated mintpass dispenser contract’s dispense methods on chain.

Once holding a mintpass, the next step on the minting journey is to reserve an IP-NFT token id by calling the IP-NFT contract’s reserve() method. This capturing step is necessary because the legal documents attached to the final IP-NFT are referring to the NFT’s token id that only becomes available after the mint has occurred. Minters will use the token id to craft the legal documents that outline the rights and obligations of owning that NFT in the real world. A selection of premade contract templates for IP-NFTs can be found on Github.

Assemble and Upload Metadata

The JSON metadata documents behind IP-NFTs are required to strictly validate against a well defined JSON schema that’s flexible enough to cover many relevant use cases. Here’s a visual tool to investigate a valid IP-NFT’s metadata interactively. Note that the generic fields name, image and description are located on the document’s root level as required by ERC-1155, whereas the agreements and project_details structures are modeled as rich property definitions.

{
  "schema_version": "0.0.1",
  "name": "Our awesome test IP-NFT",
  "description": "Lorem ipsum dolor sit amet, ...",
  "image": "ar://7De6dRLDaMhMeC6Utm9bB9PRbcvKdi-rw_sDM8pJSMU",
  "external_url": "https://ip-nft.com/1",
  "properties": {
    "type": "IP-NFT",
    "agreements": [
      {
        "type": "License Agreement",
        "url": "ar://4FG3GR8qCdLo923tVBC85NTYHaaAc3TvCsF3aZwum_o",
        "mime_type": "application/pdf",
        "content_hash": "bagaaiera7ftqs3jmnoph3zgq67bgjrszlqtxkk5ygadgjvnihukrqioipndq",
      }
    ],
    "project_details": {
      "industry": "Pharmaceutical R&D",
      "organization": "Newcastle University, UK",
      "topic": "Aging",
      "research_lead": {
        "name": "Chuck Norris",
        "email": "chuck@norris.com"
      }
    }
  }
}

Validate Metadata Correctness

To validate IP-NFT metatadata documents against that schema, you can use arbitrary JSON schema tools. Ajv is one of the most powerful ones in Javascript. We’re omitting the code to retrieve schema or documents for brevity’s sake but in a nutshell validation boils down to:

import Ajv from "ajv";
import addFormats from "ajv-formats";

(async () => {
  const ipnftSchema = JSON.parse(ipnftSchemaJson);
  const document = JSON.parse(ipnftMetadataJson);
  const ajv = new Ajv();
  addFormats(ajv);
  const validateIpnft = ajv.compile(ipnftSchema);
  const validationResult = validateIpnft(document);  
})();

Link to External Resources

IP-NFT metadata documents require you to refer to external resources, e.g. the image or agreements[].url fields. While you can choose to go with the well known https:// protocol, it’s advisable to use web3-native decentralized storage pointers like ar:// or ipfs:// instead. Clients are supposed to resolve them to their respective http gateway counterparts and most NFT related services and frontends can handle them. You don’t need to run an Arweave or IPFS node yourself - Ardrive or web3.storage are excellent helper services that get the job done and our official IP-NFT minting UI uses Bundlr to efficiently upload files to the Arweave network with near instant finalization.

Here’s a nodejs example on how to upload a JSON document using web3.storage (it’s simpler to do this within a browser context, though):

import dotenv from "dotenv";
import { Blob } from "node:buffer";
import { Web3Storage } from "web3.storage";
dotenv.config();

const w3sClient = new Web3Storage({ token: process.env.W3S_TOKEN });
(async () => {
  const content = {
    uploaded_at: new Date().toISOString(),
  };
  const binaryContent = new Blob([JSON.stringify(content)], {
    type: "application/json",
  });
  const file = {
    name: "filename.json",
    stream: () => binaryContent.stream(),
  };
  //@ts-ignore
  const cid = await w3sClient.put([file], {
    name: "some.json",
    wrapWithDirectory: false,
  });
  console.log(cid);
})();

results in an IPFS CIDv1:

bafkreicrhuxfzrydht6tmd4kyy6pkbhspqthswg6xbiqlaztmf774ojxhq

To resolve the published content, you can request it from any public IPFS http gateway. You’ll experience the lowest latency when querying a gateway close to the node that you used for uploading; web3.storage offers https://w3s.link for that purpose. Requesting https://w3s.link/ipfs/bafkreicrhuxfzrydht6tmd4kyy6pkbhspqthswg6xbiqlaztmf774ojxhq yields

{"uploaded_at":"2023-01-02T22:45:17.788Z"}

Decentralized Encryption and IP-NFT Token Gating

An IP-NFT’s most important metadata property are its agreements, another term for legal documents attached to it. These documents refer to the IP-NFT smart contract’s (“collection”) address and the IP-NFT’s token id. The agreements’ content might contain confidential information about the involved parties and hence should be encrypted before being uploaded. Decentralized and permissionless encryption is a non trivial requirement that we solve by relying on Lit Protocol.

Lit runs a network of nodes that derive signing and encryption keys by multiparty computation / threshold cryptography on trusted computing enclaves. The nodes themselves only know parts of the private key that effectively is fully assembled on the client side after all conditions for key retrieval have been met. Lit protocol allows gating any content behind access control conditions that are backed by blockchain state, therefore it’s disclosing decryption keys only to holders of an NFT or users that meet a certain condition on chain.

Lit’s documentation lays out the encryption process in detail. To instantiate a Lit SDK instance that’s capable of encrypting or decrypting content, it needs an EIP-4361 compatible signature that proves control over the current user’s account. Once authenticated we can request a new symmetric key to encrypt our content and ultimately ask the Lit network nodes to store its key shares along with an access control condition. That request yields an encrypted decryption key (😵‍💫) that has been created by the network nodes.

import LitJsSdk from '@lit-protocol/sdk-browser'
  
const litClient = new LitJsSdk.LitNodeClient()
await client.connect() //connects to Lit network nodes

const file: Blob | File = //some file
const { encryptedFile, symmetricKey } = await LitJsSdk.encryptFile({ file })
//you can reuse a Siwe / EIP-4361 compatible signed message here, see https://login.xyz/
const authSig = await LitJsSdk.checkAndSignAuthMessage({ chain: "ethereum" });

accessControlConditions = {
    conditionType: 'evmBasic',
    contractAddress: tokenContractAddress,
    standardContractType: 'ERC1155',
    chain: "ethereum",
    method: 'balanceOf',
    parameters: [':userAddress', tokenId],
    returnValueTest: {
      comparator: '>',
      value: '0' // user owns more than 0 of this token id
    }
  }

const u8encryptedSymmetricKey = await litClient.saveEncryptionKey({
  unifiedAccessControlConditions: accessControlConditions,
  symmetricKey,
  authSig,
  chain,
  permanent: false
})

A user who wants to decrypt the content must again initialize the SDK using a signed message that proves control over their address. Next, they ask several network nodes to present their key shares of the encrypted key by presenting the access control conditions and the encrypted symmetric key to the network. If the network nodes find that the account matches the given conditions, each one yields its key share for the encrypted decryption key. With that, the SDK decrypts the key the content has initially been encrypted with.

const authSig = await LitJsSdk.checkAndSignAuthMessage({ chain: "ethereum" });
const symmetricKey = await litClient.getEncryptionKey({
    unifiedAccessControlConditions: accessControlConditions,
    toDecrypt: encryptedSymmetricKey,
    chain: "ethereum",
    authSig
})

An IP-NFT metadata’s agreements item can store the encrypted symmetric key and its access control conditions inside its encryption field. Note that the IP-NFT JSON schema of access_control_conditions is externally defined by Lit protocol.

"agreements": [
  {
    "type": "License Agreement",
    "url": "ar://4FG3GR8qCdLo923tVBC85NTYHaaAc3TvCsF3aZwum_o",
    "mime_type": "application/pdf",
    "content_hash": "bagaaiera7ftqs3jmnoph3zgq67bgjrszlqtxkk5ygadgjvnihukrqioipndq",
    "encryption": {
      "protocol": "lit",
      "encrypted_sym_key": "fcbeaf3af31c7104d1d1f7099a6c6f6fda5803a4f7a0bef93256f3377450291872ad07bed3e9402cb47cc932c8f48219e56b84c06becd5ec0ee83ef2c0c93b932fb675c7932fa8df0ad164f17642b32415e382081577a403c19da2eff22c9083fa134ad1f370c2bec449adcdea790498637c7238b7d67cf2d69507a962656d3200000000000000205e4ad4e6323e06862babc934f740bc2e566d175a5da23bb4f1b35635e5cc3768cd040e8776307ea038484ff42033c18f",
      "access_control_conditions": [
        {
          "conditionType": "evmBasic",
          "contractAddress": "0xa1c301d77f701037f491c074e1bd9d4ac24cf5e5",
          "standardContractType": "ERC1155",
          "chain": "goerli",
          "method": "balanceOf",
          "parameters": [
            ":userAddress",
            "6"
          ],
          "returnValueTest": {
            "comparator": ">",
            "value": "0"
          }
        }
      ]
    }
  }
]

Using Multisig Wallet Signers

Due to the high value nature of IP-NFTs you might feel tempted to use a multisig wallet for the minting process, maybe because you’d like to prove that the IP-NFT has been created by a dedicated group of individuals. This works fine for all contract function invocations but is not supported by Lit protocol. Multisig wallets (or contract wallets to be precise) cannot sign messages in the way it’s required to authenticate against Lit nodes because they’re not based on a private key. This might once be possible by utilizing EIP-1271 compatible wallet signatures but is not supported at the time of writing.

The recommended workaround is to denote a dedicated trusted member of the multisig that’s supposed to initially own the minted IP-NFT. This could be the researcher, a core contributor or maintainer of the project. The IP-NFT contract’s mintReservation function takes a recipient parameter (to) that defines the NFT’s initial owner. Note, that the account that invokes the mint function is required to hold a mint pass, not the receiver.

Granting Read Access to Third Parties

Another shortcoming related to Lit’s requirement of private key based authentication signatures is that multisig token holders cannot prove their address to the protocol. To allow multisig members to decrypt the accompanying agreement documents, the IP-NFT contract contains a grantReadAccess. It can be invoked by the current token holder (e.g. a multisig) to grant certain accounts (e.g. some of their members or potential buyers) read access to the underlying content for a limited amount of time. Its counterpart canRead yields a boolean whether the reader is currently allowed access. For the current owner of an IP-NFT this method always returns true.

To make read grants work inside Lit protocol, one can craft a custom contract access control condition that not only takes the current IP-NFT ownership into account but also lets users pass that currently are granted read access:

"encryption": {
  "protocol": "lit",
  "encrypted_sym_key": "...",
  "access_control_conditions": [
    {
      "conditionType": "evmContract",
      //the IP-NFT UUPS proxy contract address
      "contractAddress": "0x36444254795ce6E748cf0317EEE4c4271325D92A",
      "chain": "goerli",
      "functionName": "canRead",
      "functionParams": [
        ":userAddress",
        "10"
      ],
      "functionAbi": {
        "name": "canRead",
        "inputs": [
          {
            "internalType": "address",
            "name": "reader",
            "type": "address"
          },
          {
            "internalType": "uint256",
            "name": "tokenId",
            "type": "uint256"
          }
        ],
        "outputs": [
          {
            "internalType": "bool",
            "name": "",
            "type": "bool"
          }
        ],
        "stateMutability": "view",
        "type": "function"
      },
      "returnValueTest": {
        "key": "",
        "comparator": "=",
        "value": "true"
      }
    }
  ]
}

Proving Content Integrity

Since agreement documents are encrypted before being stored, each agreement item may contain a content_hash that downloaders can use to prove the legal documents’ content integrity after they’ve decrypted it. When using IPFS as storage layer this hash is not adding much value since the network’s content ids already provide an untamperable way of guaranteeing content integrity, however they’re not derived from the original content and hard to prove without an IPFS node at hand.

The content_hash field shall contain the sha-256 digest of the attachment’s binary content, encoded as a multihash compatible to CIDv1. This allows clients to decode the content hash and verify a document’s content without being aware of the hashing algorithm used. This is how it looks like in Typescript using the multiformats NPM package:

import { CID } from "multiformats/cid";
import * as json from "multiformats/codecs/json";
import { sha256 } from "multiformats/hashes/sha2";

const checksum = async (u8: Uint8Array) => {
  //https://multiformats.io/multihash/
  const digest = await sha256.digest(u8);
  return CID.create(1, json.code, digest);
};
const verifyChecksum = async (
  u8: Uint8Array,
  _cid: string
): Promise<boolean> => {
  const cid = CID.parse(_cid);
  //https://github.com/multiformats/multicodec/blob/master/table.csv#L9
  console.log("hash algo used: 0x%s", cid.multihash.code.toString(16));
  const digest = await sha256.digest(u8);
  return cid.multihash.bytes.every((el, i) => el === digest.bytes[i]);
};
(async () => {
  const binaryContent = new TextEncoder().encode("This is the content");
  const cid = await checksum(binaryContent);
  const valid = await verifyChecksum(binaryContent, cid.toString());
  console.log(cid, valid);
})();

Putting it all together: The IP-NFT Minting Flow for Developers

To sum up, minting an IP-NFT technically requires the following steps:

• Get a Mintpass for the account that’s supposed to finally invoke the mintReservation function.
• invoke the IPNFT contract’s reserve() function to reserve a token id. This will revert if the caller is not holding a valid Mintpass. Get the reserved token id by parsing the method’s event logs
• upload an image to a (de)centralised network of your choice
• use the token id and the IPNFT contract’s address to create legal documents
• compute a checksum over the original documents
• optionally encrypt the documents with a Lit access control condition
• assemble a metadata structure containing the file pointers, access control conditions, encrypted symmetric key and checksum
• verify that this metadata structure is valid
• upload the metadata to a (de)centralised network of your choice
• invoke mintReservation on the IPNFT contract with

address to: the recipient of the minted NFT (e.g. a Multisig wallet)
uint256 reservationId: the token id you’ve reserved
uint256 mintPassId: the Mintpass id that’s going to be redeemed during the mint
string memory tokenURI: the URI that resolves to the metadata

Conclusion

IP-NFTs are DeSci primitives that allow researchers, institutions and laboratories to prematurely mint the legal implications of their work as a tradable and verifiable asset. They deal as fundamental ownership anchors that can be used to refer and gate access to other kinds of protectable content, e.g. machine learning models, data streams or non public documents. Being built on well known standard interfaces, they can be traded or fractionalized using a vast range of protocols that already exist today.

As you have learnt here, the minting process of IP-NFTs is not a trivial task, particularly if they’re containing references to encrypted content. However, their metadata schema is designed to be flexible enough to cover many IP related use cases and the IP-NFT’s contract interface should be simple to interact with.

The IP-NFT contract is deployed as an upgradeable contract that’s maintained by the Molecule core team and we’re planning to add more exciting features to it in the near future. You can find all relevant sources on our official Github repo and runnable versions of the code samples depicted in this article in the accompanying samples repo.

• How to separate concerns into different contracts?
• Verifying ownership and allowing preliminary minting
• How to ensure that no one can cheat on metadata?
• Combined Token IDs
• Shall we reduce gas fees by moving to an L2 network?
• How to reduce storage costs?
• How to keep payments safe?

First a quick overview of what we’ve built: Splice lets you use NFTs you already own to seed a new generated NFT. Just visit our Dapp at https://getsplice.io and select one of your NFTs. Splice will extract its metadata and colors, and inject that into the code of a generative art style you choose. The result is a unique artwork you can mint as an NFT. We’re launching with art styles to generate banner images you can seed with your PFP and use on Twitter or Discord, like this:

Splice scales beyond banner images and will evolve in various ways. Our contracts are prepared to take more than one NFT as origin and we’ll ultimately hand over far more input parameters to the style code, including the origin NFT’s traits, additional image analysis data or rarity scores. That’ll enable artists to build styles for far more advanced use cases. Splice will be able to select Loots or Colors or DevDAO’s NFTs as inputs and create new metaverse items.

This idea took us into the finale of EthOnline21. You can watch our final project pitch on the hackathon’s version of Splice from October 21 here (7:16):

This is how our Dapp looks like after roughly 2 months of finetuning and feature additions. Feel free to give it a try — at the time of writing we support previewing styles on your mainnet assets and you’ll be able to mint Splices on selected collections on the Rinkeby test network.

How to separate concerns into different contracts?

Our Splice contracts cover two major usecases. First, the Splice contract itself is an ERC721 compatible NFT that tracks ownership of minted splices. Second, Splice’s styles are managed by another contract (Splice Style NFT) that controls ownership of styles and stores the fixed locations of style code and its metadata. Each style NFT enforces rules like how many splices of a style can be minted, whether minting is restricted to certain origin collections, if a minter has exclusive minting rights and, most importantly, how expensive a mint is.

To separate concerns we decided to split the Splice architecture into three contracts: Splice, Style and PriceStrategy(Static). We’re wiring up all these contracts during the deployment / the style minting process by keeping member properties typed as the composed contract.

contract Splice {

  SpliceStyleNFT public styleNFT;

  function setStyleNFT(SpliceStyleNFT _styleNFT) public onlyOwner {
    styleNFT = _styleNFT;
  }

  function quote(IERC721 nft, uint32 style_token_id) 
    public view 
    returns (uint256 fee) { 
      return styleNFT.quoteFee(nft, style_token_id);
  }
}

contract SpliceStyleNFT {

  address public spliceNFT;

  function setSplice(address _spliceNFT) external onlyOwner {
    spliceNFT = _spliceNFT;
  }

  function quoteFee(IERC721 nft, uint32 style_token_id)
    external 
    view 
    returns (uint256 fee) {
      fee = styleSettings[style_token_id].priceStrategy.quote(
        this,
        nft,
        style_token_id,
        styleSettings[style_token_id]
      );
    }
  function mint(
    ...
    ISplicePriceStrategy _priceStrategy,
    bytes32 _priceStrategyParameters
  ) {
    styleSettings[style_token_id] = StyleSettings({
      priceStrategy: _priceStrategy,
      priceParameters: _priceStrategyParameters
    })
 }

}

struct StyleSettings {
  uint32 mintedOfStyle;
  uint32 cap;
  ISplicePriceStrategy priceStrategy;
  bytes32 priceParameters;
  bool salesIsActive; 
  bool collectionConstrained;
  bool isFrozen;
  string styleCID;
}

contract SplicePriceStrategyStatic {

  function quote(
    SpliceStyleNFT styleNFT, 
    IERC721 collection, 
    uint256 token_id,
    StyleSettings memory styleSettings
  ) external pure override returns (uint256) {
    return uint256(styleSettings.priceParameters);
  }

}

Separation of concerns in Solidity can be an architectural challenge because once contracts are deployed, they usually can’t be changed. Our priceStrategy seems unnecessary at first glance as it just returns the static fee that a style minter has provided during the minting process. The reason we built it this way is due to forward looking assumptions. The design of smart contracts must be open enough to be extended from day one, since it’s a nightmare to change them once they carry state and are used in the wild.

Our PriceStrategy abstraction allows far more sophisticated price calculations to be added in the future, without us needing to change anything on the existing contracts. Its implementations receive enough information to enable arbitrary complex pricing strategies. A simple extension could be a linearly bonded minting fee algorithm that increases the fee slightly with every Splice mint, or a Dutch auction that varies the fee depending on the time that’s passed since the last mint.

Who gets to mint? Verifying ownership and allowing preliminary minting

Ensuring that someone owns an origin is rather simple, you just cast the origin collection’s address to an IERC721 and check that its ownerOf method yields msg.sender for the incoming token ID:

function mint(
    IERC721[] memory origin_collections,
    uint256[] memory origin_token_ids,
    uint32 style_token_id,
    bytes32[] memory allowlistProof,
    bytes calldata input_params
) {
for (uint256 i = 0; i < origin_collections.length; i++) {
      if (origin_collections[i].ownerOf(origin_token_ids[i]) != msg.sender) {
        revert NotOwningOrigin();
      }
}

But there’s more to it. An artist might decide to build a style that only works for, say, three dedicated origin collections. If that’s the case those collections’ addresses can be provided in the collectionAllowed member on our Style NFT. A style with a collection constraint will revert Splice mints when the origin collection(s) aren’t listed in the constraint list. By default styles aren’t constrained to particular collections, so Splices can be minted off any origin NFT.

Lastly we decided to add an allowList feature that’s unique to each Style NFT. If you wanted to build allowlists naively, you could just add some member of type mapping(uint32 => mapping(address => bool)) but would have to initialize that mapping when deploying a new style. If a style creator wants to have, say, 200 addresses on an allowlist, that would require a significant amount of gas to be sent along the minting transaction. Since we wanted this feature to be gas efficient, we had to come up with a better solution.

We decided to use Merkle tree proofs to determine whether a mint request is issued by an allowed user. Luckily, OpenZeppelin had us covered with their reference implementation for Merkle proofs, so implementing this feature takes only one line of actual code:

///SpliceStyleNFT.sol

function verifyAllowlistEntryProof(
  uint32 style_token_id, 
  bytes32[] memory allowlistProof,
  address requestor
) public view returns (bool) {
  return MerkleProof.verify(
    allowlistProof,
    allowlists[style_token_id].merkleRoot,
    keccak256(abi.encodePacked(requestor))
  );
}

///Splice.sol:mint

if (
  allowlistProof.length == 0 || 
  !styleNFT.verifyAllowlistEntryProof(
    style_token_id,
    allowlistProof,
    msg.sender
  ) {
    revert NotAllowedToMint('no reservations left or proof failed');
  }
)

The downside of this approach is that the allowlist members must be kept in a safe place and proofs must be generated for each user individually but since this feature deals with permissioned data anyway, it’s not necessary to solve it in a 100% decentralized way. The client code that creates the respective proof array looks like this:

import { MerkleTree } from 'merkletreejs';
import keccak256 from 'keccak256';

function createMerkleProof(allowedAddresses: string[]): MerkleTree {
  const leaves = allowedAddresses.map((x) => keccak256(x));
  return new MerkleTree(leaves, keccak256, {
    sort: true
  });
}

const allowedAddresses: string[] = [/* many 0xaddresses */]

const merkleTree = createMerkleProof(allowedAddresses);
const leaf = utils.keccak256(_allowedAddresses[0]);

// this grows linearly with the overall amount of allowed addresses
const proof = merkleTree.getHexProof(leaf);

const verified = await styleNft.verifyAllowlistEntryProof(
  1,
  proof,
  allowedAddresses[0] 
);

expect(verified).to.be.true;

Hot to ensure that no one can cheat on metadata?

Our initial implementation of Splice was based on the assumption that users are in full control of their spliced results: the code renders a Splice result on the user’s machine, encodes it as PNG, publishes that on IPFS (using nft.storage) and then calls the contract’s mint method using its IPFS content hash.

We then realized that this implementation could easily be tricked by users: they actually could feed any IPFS hash they like into the mint function, effectively being able to mint virtually anything. That’s certainly not what we wanted to allow so we came up with the idea to use an oracle that requests dedicated validation backends to validate that our users’ mint “requests” actually contain valid Splice images that match the input parameters the user had used on their machine (you find an implementation for that in our repo’s history).

With the introduction of dedicated Style NFTs we deprecated this validation step. As of now Splice itself doesn’t store any IPFS metadata at all. The only information we keep for each Splice on chain is its “provenance” which is computed during a Splice mint:

/// Splice.sol:mint

bytes32 provenanceHash = keccak256(
  abi.encodePacked(
    origin_collections, origin_token_ids, style_token_id
  )
);

The provenance (or heritage as we called it historically) is unique for each Splice input. The users themselves are not providing any other information than their desired origin inputs and a style token id that determines which style code is executed on the inputs and which itself is anchored on IPFS. Thus, anyone who knows the input that had lead to the provenance, can deterministically reproduce the rendered image.

Combined Token IDs

If you look at Splice’s token IDs, for example “12884901894”, you’ll notice they’re seemingly not generated incrementally. Basically, they are, but it’s hard to see. Splice combines two incremental IDs into one unique ID value for each token. It combines the chosen style ID and the incremental (per style) splice token id into a unique token id (uint64, stored as uint256 as required by ERC721):

/// SpliceStyleNFT

function incrementMintedPerStyle(uint32 style_token_id)
    external
    onlySplice
    returns (uint32)
{
      if (mintsLeft(style_token_id) == 0) {
        revert StyleIsFullyMinted();
      }
    
      styleSettings[style_token_id].mintedOfStyle += 1;
      return styleSettings[style_token_id].mintedOfStyle;
}

/// Splice.sol
uint32 nextStyleMintId = styleNFT.incrementMintedPerStyle(style_token_id);

token_id = BytesLib.toUint64(
  abi.encodePacked(style_token_id, nextStyleMintId), 
  0
);

This approach lets you compute the style heritage of each Splice NFT. You take its least significant 64 bits and split it into two uint32 values. The first one denominates the style ID, the second the incremental splice ID for that style:

/// Splice.ts

public static tokenIdToStyleAndToken(tokenId: BigNumber) {
    const hxToken = ethers.utils.arrayify(
      utils.zeroPad(tokenId.toHexString(), 8)
    );
    return {
      style_token_id: BigNumber.from(hxToken.slice(0, 4),
      token_id: BigNumber.from(hxToken.slice(4))
    };
  }

A token ID that decimally reads 12884901894 translates to the hex string 0x0300000006 (or padded to 8 bytes / uint64: 0x0000000300000006), so it effectively translates to “splice #6 of style #3”.

Shall we reduce gas fees by moving to an L2 network?

Minimizing additional network costs for a mint on L1 should be a primary focus for each and every web3 project. At first glance Splice actually is a good candidate for L2 minting, but doing so would introduce an additional layer of architectural complexity. Remember, Splice relies on knowledge about the ownership of certain assets (the origin NFTs). To mint a Splice, the contract must ensure that the minter actually owns their origin NFTs. If you wanted to mint a Splice on an L2 network on assets that exist on L1, you’d need to create a cryptographically deterministic proof of that ownership relationship and communicate that using a message bridge that transfers knowledge between layers. Even worse, that proof could be negated immediately after its creation by transferring the origin asset to another account which only could be remedied by locking the origin into an escrow that keeps it safe until the mint has been finalized on L2. Ultimately, you would either decide to make Splice an L2 first protocol which implies that users cannot mint Splices on mainnet or you would have to come up with a pretty smart ID gap so that users could migrate Splices from L2 to L1 that don’t collide with already existing IDs.

Given that most valuable assets are still anchored on mainnet and Splice’s primary goal is to add value to those, we believe that deploying it as a pure L1 protocol is the best way to go for now (which isn’t implying that there won’t be a Polygon, zkSync or Arbitrum version of Splice coming up anytime soon).

How to reduce storage costs?

The significant driver of high gas costs on Ethereum is data storage. Each storage slot on the state tree must be replicated by all participating nodes and the most expensive operation of them all is allocating a new storage slot, which occurs when new mapping elements are created or array elements are appended. As it turns out, one of the most convenient NFT additions of all times makes exhaustive use of these operations: Enumerable collections. They allow clients to iterate over all items of an user, which internally is solved by adding another mapping and an indexing table.

Removing this feature shaved off a third (!) of all gas points of a mint transaction and others report to have witnessed comparable results.

splicenft/gas-comparison.txt at 38bf9fad2e4889f33e912106501418f3d7570e3b · SpliceNFT/splicenft

Another storage slot we could remove from our first draft of the Splice contract was the “heritage” of a Splice token. Turns out the only information that needs to be stored directly on chain is the provenance hash (32 bytes) of a Splice’s heritage to figure out whether an item already had been minted. This optimization reduced the amount of gas used for a mint by another 30%.

Where to store the origin information then? The Graph to the rescue!

With every storage slot that you save on chain you lose some amount of functionality. When applying the aforementioned optimizations we lost two important view functions that formerly could be requested directly on chain: 1. what is the exact origin of a Splice token and 2. which Splice tokens are owned by an account.

It turns out both features are perfect candidates to be indexed by and queried from a subgraph. Subgraphs consist of WASM (AssemblyScript) based indexing scripts that are executed on indexer nodes to build up a secondary database of onchain information and make it publicly queryable using a GraphQL API. Though The Graph offers a fully decentralized way to deploy subgraphs on an incentivized indexing and curation layer, we chose to go with their pretty convenient (and free) hosted service.

A subgraph mapping listens to the events emitted by a contract and reacts to them accordingly. In Splice a minting transaction emits two events: a custom Minted(bytes32 origin, uint64 token_id, uint32 style_token_id) and Transfer (emitted by the base ERC721 contract). Note that you still cannot figure out the origin collection or token id just by following Minted events: what we actually have to analyze are the transaction inputs for the mint call that emitted the event. Our subgraph’s handleMinted handler shows how to achieve that:

After extracting some unencoded values from our Mint event we’re getting the input data of the initiating mint method call (line 18) and strip off the method signature’s first 4 bytes. Now we’re hitting a shortcoming of the underlying ABI decoder’s Rust implementation: it can only decode single values, e.g. tuples, uints or arrays but it is not capable of decoding plain function calls directly like those stored in event.transaction.input. The cheat we used to trick the decoder into decoding our function calls correctly is to prefix the argument with the ABI encoder’s signature for tuple types (0x20) and have the decoder operate on that value instead (line 21–32):

const decoded = ethereum.decode(
    '(address[],uint[],uint,bytes32[],bytes)',
    tupleInputBytes
);

We’ve also created a Rust sample that proves this approach to work:

splicenft/main.rs at main · SpliceNFT/splicenft

The Splice subgraph is openly available for queries on The Graph’s hosted service: https://thegraph.com/hosted-service/subgraph/elmariachi111/splicemultirinkeby and it powers e.g. the “My Splices” page of the Splice Dapp. (Note, that for still undiscovered reasons the GraphQL schema’s plural version of splice is spliceice)

How to keep payments safe?

Finally we took great care that all payments hitting our contracts are kept as safe as possible with regards to Consensys’ smart contract best practices for security. We’re not pushing minting fees to the recipients but rather ask them to withdraw them by issuing a pull transaction themselves. To keep funds safe for all participants we’ve integrated an internal token escrow that only transfers funds to entitled participants and that’s owned by the main contract so nobody could hijack the escrow itself. Upon minting all fees are split according to the currently active protocol settings (85% for artists, 15% for Splice) and escrowed until withdrawn by their beneficiaries:

import '@openzeppelin/contracts-upgradeable/utils/escrow/EscrowUpgradeable.sol';

EscrowUpgradeable private feesEscrow;

function initialize(...) public initializer {
  /// ...
  feesEscrow = new EscrowUpgradeable();
  feesEscrow.initialize();
}

function withdrawShares() external nonReentrant whenNotPaused {
    uint256 balance = shareBalanceOf(msg.sender);
    feesEscrow.withdraw(payable(msg.sender));
    emit Withdrawn(msg.sender, balance);
}

function shareBalanceOf(address payee) public view returns (uint256) {
  return feesEscrow.depositsOf(payee);
}

//called inside the mint method
function splitMintFee(uint256 amount, uint32 style_token_id) internal {
  uint256 feeForArtist = ARTIST_SHARE * (amount / 100);
  uint256 feeForPlatform = amount - feeForArtist;
  address beneficiaryArtist = styleNFT.ownerOf(style_token_id);
  feesEscrow.deposit{ value: feeForArtist }(beneficiaryArtist);
  feesEscrow.deposit{ value: feeForPlatform }(platformBeneficiary);                                 }

Rollup

We certainly could’ve talked about a lot of other learnings we’ve discovered during the implementation of the Splice protocol. First and foremost we can recommend one thing, though: read the code of public contracts yourself! You’ll stumble upon a lot of stuff others have figured out before you. In our case we learnt a lot by analysing the contracts of ArtBlocks, Brotchain and Divine Anarchy.

If you like what you’ve read and you want to become part of the Splice journey, don’t hesitate to approach us directly on Discord or on Twitter. You also might find it helpful to read our documentation for developers to gain more insights about the Splice protocol’s inner workings. We’re happy to take any questions and suggestions.

Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing

Also Read

• An ultimate guide to Leveraged Token [Bull Token]
• Best Crypto Exchange | Top 10 cryptocurrency exchanges 2022 | CoinCodeCap
• Best Crypto Swap Platforms in 2022 | CoinCodeCap
• 6 BEST Crypto Lending Platforms — Crypto Loan Sites
• 11 Best Hardware Wallet Reviews & Comparisons 2024
• 10 Best FREE Crypto Trading Bots in 2023
• 5 Best Crypto Telegram Channels 2024 (Trading Signals)
• Bitsgap Review - Trading Bots Crypto Signals and Arbitrage 2022 | CoinCodeCap

7 Key Insights for Smart Contract Developers: What We’ve Learned Building Splice was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the past couple of months, we’ve been onboarding at least a dozen web3 developers to our team. In order to get them started, we’ve written numerous demos, built prototypes, and even initiated an internal Confluent “ledger academy”, which gets lost in so many details you can spend an entire week parsing through it. Fact is: if you’re looking to get started, the interwebs already contain countless useful resources to help you. Still, for those just setting out on their web3 journey, it can be really overwhelming.

So, I decided to assemble this guide to point you in the right direction, as well as answer some questions that I have answered many times over during onboarding processes. If you want to get started for real, make sure to follow all the official sources I’ve listed. The goal of this document is to walk you from “basic” to “advanced”. If I’m missing something valuable, please let me know in the comments.

Much of the code you’ll read throughout this document is written in TypeScript. Why? Decentralized applications’ frontends usually run inside browser contexts. Plus: we cannot think of any chain, protocol or service that doesn’t come with a Javascript-compatible SDK. So, we’re considering Java-/Typescript the lingua franca to working with decentralized tech stacks. If you’re not familiar with it: NVM lets you install many different, isolated local node instances without leaving any traces on your harddisk, yarn and pnpm are splendid package managers and Visual Studio Code is an IDE that will never let you down.

A side note on the overwhelmingly hard to understand Javascript’s “bundler” ecosystem: we found that building web3 applications using the latest bundlers / compilers like esbuild, Vite or even Parcel is depressingly unpredictable. We definitely recommend staying on the established Create React App / webpack bundling track (Nextjs is also a fantastic framework to build decentralized apps).

web3: a primer

Web3 is a collective phrase for decentralized tech stacks. It’s mostly associated with Ethereum / IPFS but it’s also a heavily used phrase for Polkadot / Kusama / Substrate / Solana apps. In a nutshell, it stands for any application that doesn’t rely on a “Single Point of Failure”. More precisely, it describes a way of development, deployment and interaction of applications that are unstoppable and uncontrollable by anyone, thanks to distributed infrastructure such as blockchains.

Web3 apps are permissionless by definition. Everyone can access and interact with them. That doesn’t mean everybody can do what they want; there are well known methods to add access restrictions, role based access and even identity checks to protect them from random access. In contrast to traditional role management systems, those rules are enforced by cryptography and blockchain-based smart contracts. Once written correctly, they are fully uncompromiseable and unbreakable.

Since web3 apps are running in a decentralized environment, they’re also referred to as Dapps. While not restricted to them, Dapps mostly make use of either “content addressable storage networks” such as IPFS, and some kind of unstoppable, consensus based database, most likely a blockchain such as Ethereum.

Ethereum: a world computer.

Ethereum is an account-based blockchain running on interplanetary scale that executes custom binary code during transaction validation. It’s (still) using a Proof of Work consensus model that incentivizes miners to spend a lot of computing power to secure the network. Ethereum (mainnet) is migrating towards a dramatically more environment friendly Proof of Stake Consensus since 2015 and the current ETA of that “migration” is around 2022.

Both consensus models are proven to be secure in a massively adversary environment and they are locking hundreds of billions of USD value on many chains. There are lots of other consensus models out there and most of them deal with increasing transaction throughput, ease of setup, resource optimization etc. Though, to be honest, as of today not one of them has been proven to work as well as PoW.

The original “distributed consensus” term goes back to fail safe systems from the 70s, where people described the “Byzantine Generals Problem” leading to algorithms like PBFT (see Cosmos / Tendermint). Other very well understood (permissioned and not distributed) consensus algorithms are Paxos and Raft, which are used in distributed database / event streaming systems such as Apache Cassandra, Kafka or etcd.

Do you actually need a blockchain?

A common question people ask is: “Do you actually need a blockchain for this?” and mostly the answer will be no. For a lot of traditional business applications, using blockchain technology doesn’t add much value, but tenfold more complexity instead. There are two reasons when introducing blockchain technology makes absolute sense, though.

• First, when you need to interact with other economic parts on an existing, most likely public blockchain. On Ethereum, you find ten thousands of contracts that keep trillions of tokens, are worth billions of dollars and are all publicly available, waiting to accept your transactions.
• Second, if you’re building huge industrial consortia consisting of hundreds of players that neither know nor trust each other nor can agree on common infrastructure components.

Blockchains bear a promise of total transparency and interoperability. That’s why they are an ideal tech stack to build database-like systems that many partners can attach to without having to deal with ever changing API definitions or political onboarding processes. Identity ledgers like Sovrin / Indy or global supply chain systems with thousands of unacquainted logistics partners are very good candidates.

You most certainly will not need blockchains to enhance operations of only one company and you for sure won’t need one to run behind a single ecommerce application (which might be a different story if you’re building global marketplaces as we do at Turbine Kreuzberg).

Smart Contracts

Ethereum is the foundational tech stack for blockchain based applications. Even though it can seem hard to grasp in the beginning, it’s really the simplest to understand. As a developer, you don’t have to understand all of its inner workings. Still, there is one thing you really must get: you can write programs on your local machine in various programming languages, the most prominent one being Solidity, a Turing complete language, you compile them with a binary / intermediary compiler (solc), wrap the resulting byte code in a transaction and “deploy” that to the Ethereum blockchain.

The deployed code is what is called a “smart contract”. It can be accessed by all other acting entities on the Ethereum chain, either Externally Owned Accounts (EOAs), which are humans or wallets operated by bloodbags or other smart contracts. The runtime that executes smart contracts is called “Ethereum Virtual Machine” / EVM. Since contract code is triggered by transactions that are issued on a globally consented unique application state, the result of its execution will lead to exactly the same result every single time. Therefore, smart contracts are nothing but a fully deterministic, distributed state machine.

Wallets and Keys

Let’s quickly define what we mean by interacting here: every operation on the Ethereum ledger is triggered by something called a transaction. In its simplest form, a transaction is moving funds from one account to another. Most often, they’re used to invoke functions on smart contracts. Each transaction is signed with the private key of an EOA (a user) and can contain payload data.

Private keys are the fundamental security guarantee, your “login credentials” to the blockchain world, if you will. They’re an ultimate secret and are therefore kept inside wallet applications secured on the end users’ devices. Usually a “wallet” represents some 32 byte random seed number that can be recovered by / stored in a 12 / 24 words phrase, which you should put on a piece of paper and store in a secure place (read: not digitally!). You can use this seed phrase to recover your random wallet seed and derive an arbitrary amount of accounts from it using a keychain derivation path according to BIP-32 (official source). Note: inthe developer world a seed phrase is often referred to as Mnemonic. The most well known and widely used wallet in the Ethereum space for developers and users alike is called Metamask, a browser extension you should download and install right now.

WARNING — Even though this should be obvious, never, ever, on an astronomical scale of endless NEVER! should you use your seed phrase anywhere other than in a wallet application you trust. Don’t even put it on any “trusted” cloud setup, don’t copy and paste it into computer memory and for sure not on any website, for god’s sake. Don’t even think about sending it in an email! It belongs to you. When developing, make quadruple sure that the seeds you use for development are really different from the ones you use privately.

Transaction Priority / Gas

A final concept to understand for decentralized apps is how they deal with congestion. If everyone in the world tries to update the global state at the same time, a distributed state machine based on a single state tree (as Ethereum is) cannot write all their transactions simultaneously. It must wait for the global consensus layer to agree on a transaction ordering. This imposes a major bottleneck in the operational speeds of blockchain networks. That leads us to the question: how does the protocol know, under high load, which transactions it should accept first? Ethereum’s answer (and there are others) is the concept of Gas.

Gas is a virtual value unit that is required by the EVM to execute any state changing code. When a transaction triggers smart contract code and this code will change the contract’s state (e.g. their account balance) during execution, e.g. by assigning a new value to a member variable of the contract, this opcode execution costs a predefined amount of Gas.

Gas itself doesn’t translate to a monetary value. Instead, users of the network must estimate a competitive price compared to all other users (commonly calculated in a fractional unit of Eth, the so called Gwei or Shannon) for their transaction. They then send this amount along with their transaction, effectively making it a transaction fee. Gas is “consumed” during contract execution and surplus gas is refunded to the caller’s account. If your transaction fails because the executing smart contract reverts its execution, you won’t lose any assets involved in that transaction, but you’ll lose the gas you sent along.

An advanced word of notice: before the rollout of EIP-1559, all gas costs had been paid out as an incentive for block miners, which led to a somewhat overincentivized network situation, where people earned far more money than necessary for the security and stability of Ethereum. After EIP-1559, gas is consumed by miners totally differently than it has been before (the so called “base fee” is actually burnt by the protocol), but you as a developer shouldn’t notice the effects of this update at all.

You can find deep introductions on Ethereum at Ethereum’s funding company Consensys, and more developer centric introductions at EthHub. As I said, the most used wallet app by far is Metamask, which runs as browser extension or as a mobile app (React Native). You can also start with the very basics and sign transactions using Consensys’ official EthSigner, or choose another Dapp wallet.

There’s a deep official documentation for Solidity and you can code right away using the browser based Remix IDE or using Visual Studio Code extensions. To play around with seed phrases and keys, here’s a basic hd wallet repo, and the Truffle Suite’s HD Wallet provider or the “original” EthereumJS wallet repo.

Network Nodes, Private- and Testnets

The fundamental idea of blockchains is that you don’t have to (read: must never) trust anyone to add transactions to the ledger database — no bank, no service, no SaaS. Hence you can run a blockchain node on your own machine and talk to it via its JSON-RPC interface (which is a tiny spec to invoke exposed functions using JSON objects, eventually using HTTP as transport layer).

While it’s certainly fun to do so, you don’t need your own node to interact with any network (besides your local, single node devnet of course, see below). Services like Alchemy, Infura or Anyblock offer access with quite generous free tiers to Ethereum nodes on all networks. Dapps that run in browsers and are connected to Metamask actually access the blockchain nodes that Metamask relies on (they’re effectively run by Infura, a Consensys company).

But let’s say you’re feeling adventurous and want to run it for yourself. That’s why we’re developers, right? Then you have several options for Ethereum: the official node software is Geth (Go), a formerly abandoned and now slightly more active one is OpenEthereum (Rust) and then there’s Besu (Java, Hyperledger / IBM) and Nethermind (.NET).

In their default config, all those Ethereum clients are compatible to Ethereum mainnet: upon startup they’ll try to find neighbor nodes, exchange messages with them, download block headers, verify and rebuild the Ethereum chain state on your machine and finally join the network. You can even use those nodes to mine Ethereum blocks on your own, but that’s far out of scope of this article and totally unfeasible to achieve on average developer boxes.

Syncing Ethereum mainnet is a humongous task and needs a lot of computing power, RAM, bandwidth and storage alike (you’ll need Terabytes of NVMe SSD space!). Depending on the client you use, you have several options to sync. In Geth terms they’re called “light”, “fast” and “full” and you can activate a “tracing” feature that will add even more state data to it.

If you want to use a node to simply interact with smart contracts, a non-archive node does the job. Syncing requires ~3–7 days on a well equipped machine. Archive nodes keep state trees for all chain states in history and consume more than 7TB SSD hard disk space. They can be used if you want to analyse smart contract history, e.g. when writing applications that need to figure out what happened in the past to do predictions about the future, writing wallet apps with history support or chain explorers.

As a developer, you certainly won’t start your Ethereum development endeavours on mainnet. Therefore, the community is running 4 official testnets which differ in consensus protocols and speed, but from a developers perspective they’re perfectly compatible to mainnet: Ropsten, Kovan, Rinkeby and Goerli. Most of those networks are either set up with a low difficulty PoW or use a controlled consensus module, also known as “Proof of Authority” that allows predefined signers (or sealers or verifiers) to sign and issue blocks.

The Ethereum base currency has no real value on testnets so you can use faucet apps which are giving away testnet Ether for free (Ropsten, Kovan, Rinkeby, Goerli). Which testnet is best suited for your development needs depends on many factors, and they’re not all stable all the time. Here’s a Stackoverflow answer that might clarify things better than I ever could. To sync the Goerli testnet using geth, you simply can:

geth --goerli --syncmode "full" dumpconfig > goerli.toml
geth --goerli --config goerli.toml

and depending on your bandwidth your node should be in sync after ~10 hours of downloading and validation. At the time of writing (2021) the full Goerli blockchain consumes around 43GB of harddisk space.

Running a local network / devnet

You can actually use Ethereum clients to setup your very own PoA network, too, which requires running several nodes and validators that operate on the Clique or AuRA PoA consensus modules.

Deploying and executing smart contracts on testnets still is cumbersome, error prone and laggy, so as a developer you can go for a much simpler solution: running your very own Ethereum devnet locally. For this you only need a node that runs on the most primitive, unvalidated “instant seal consensus”. The most well known node software to run a local Ethereum devnet is ganache (part of the truffle suite). You can run it as a standalone desktop app which comes with its own chain explorer or using Docker. Here’s a docker-compose snippet we often use to share a ganache instance with several apps:

version: "3.7"
services:
  ganache:
    image: trufflesuite/ganache-cli
    entrypoint:
      - node
      - /app/ganache-core.docker.cli.js
      - --deterministic
      - --db=/ganache_data
      - --mnemonic=${MNEMONIC}
      - --chainId=5779
      - --networkId=5779
      - --gasPrice=5e9
    volumes:
      - .ganache:/ganache_data
    ports:
      - "7545:8545"

For testing reasons you can run a fully fledged ganache node right inside your test suite. This is how we do it:

//@ts-ignore
import ganache from 'ganache-cli';
import Web3 from 'web3';

const MNEMONIC = '...';

const provider = ganache.provider({
    mnemonic: MNEMONIC,
    total_accounts: 10,
    default_balance_ether: 100
});
const web3 = new Web3(provider);

export default web3;

Now is the right time to wonder about the “provider” and “web3” objects. Let’s dig into them.

Interacting with Ethereum from your code: web3.js, ethers and providers

It’s sometimes hard to decide the terms “agent”, “wallet” and “provider”. Most commonly a provider is a service object that connects to a node and talks to it using its low level JSON RPC API. Additionally, a provider is usually “authenticated” upon construction, which means that it acts on behalf of the user. When writing non production code or tests, you’re usually using providers with direct access to private keys or Mnemonics but in a real environment you’re talking with a given provider’s web3 interface so you’ll never get in touch with a user’s private key or seed phrase.

Mental note: you will never ask for any user’s private key, even if it might simplify your life. If you’re tempted to do so, you certainly need to learn more about wallets, their APIs, environment variables or different ways to implement the problem you’re trying to solve.

For now, here’s a simple code sample that starts a local Ganache based Ethereum node and then uses web3.js to interact with it. When visiting the /transact endpoint, it’ll send 1_000_000 wei (the smallest amount you can break an Ether into) from account[0] to account[1] and displays the transaction receipt.

Note, that web3.js uses a (rather weird, but very practical) concept of PromiEvents that mix a promise with an event emitter. The local Ganache node creates a block with that transaction immediately so another call to / will show you the current balances. In a real world application (also on testnets), the transaction will take some time (15 seconds on testnets, longer on mainnet) to pass through the consensus protocol. You can use the event emitter part of a PromiEvent to listen for transaction confirmations and finality.

On a high level, you just witnessed how transactions are published to the Ethereum network, using web3’s sendTransaction method:

const receipt = await web3.eth.sendTransaction({
    from: accounts[0],
    to: accounts[1], 
    value: 10*1e5
})

That looks fairly simple, but there’s quite a bit of stuff going on under the hood:

• it checks whether the bound provider to web3.eth has access to the wallet of accounts[0]. It has, because that’s how we created it.
• it assembles an Ethereum transaction request object out of the given parameters.
• it guesses a gas limit (maximum gas for execution) for the operation involved (transferring an eth value from one account to another costs 21000 gas)
• it increments the latest nonce of account[0] so the chain knows about the ordering of incoming transactions of that account.
• it guesses the right network configuration for the transaction according to the underlying provider object.
• it uses account[0] ‘s private key to sign the transaction object.
• it assembles a signed transaction request that looks like:

{
    "nonce": 4,
    "gasPrice": {
      "type": "BigNumber",
      "hex": "0x0f4240"
    },
    "gasLimit": {
      "type": "BigNumber",
      "hex": "0x5208"
    },
    "to": "0x6FaAB23372f372aB4B8F70C54CD15b4262847f32",
    "value": {
      "type": "BigNumber",
      "hex": "0x0f4240"
    },
    "data": "0x",
    "chainId": 0,
    "v": 27,
    "r": "0xb41e39cbee80b6a2d4d7ab7754553e3ac36901fc00656aad407d032650eb72e7",
    "s": "0x1230e25a4968cb62bbdd0aa857f6886ff810f03ef7339d20413e45955ed0038a",
    "from": "0xDC0a90a51E34D7b497df931679b47e0697B82d5E",
    "hash": "0xee24c3cd5f2bc9ce0eb429c67e08ee959233526958bf1b497c440f3a3a7caeac",
    "type": null
  }

• it promotes the signed transaction in binary encoding to the provider, using JSON-RPC
• it passes through the transaction receipt to the client
• it attaches a subscriber to the provider to get notified when the transaction is finally confirmed.

ethers.js

Besides web3.js, there’s the acclaimed ethers.js library, which is getting even more attention than web3.js lately and for many reasons. The most crucial difference is its consequent distinction of providers and signers. To demonstrate that, I rewrote the above web3 example for ethers.js with manual transaction signing (ethers.js of course also comes with a sendTransactions convenience method). Again, make sure to invoke the /transact endpoint to send transfer transactions:

Smart Contract Development

While there are others, the official language to write EVM compatible Smart Contracts is Solidity. If you know how to write Javascript and have a slight idea about hexadecimals, binary operations and object oriented coding, you should be able to learn and use Solidity within days.

The simplest way of getting your hands dirty using this language is the integrated, web based IDE Remix: https://remix.ethereum.org/. It lets you code, import, compile, interact and optimize smart contract code. There are so many tutorials written on getting started with it that I won’t repeat the steps here. My reading recommendation that goes beyond trivial aspects is this story by Burakcan Ekici from end of 2020.

To give you the simplest peek possible into Solidity, consider this code example:

It demonstrates the basic concepts: a smart contract feels like a class in other languages, it contains member variables and methods, it consequently uses typed parameters and it can extend other contracts (Solidity supports multiple inheritance). One special feature lies in the so called modifiers that are inherited by parent contracts and can annotate functions. Modifiers often act as “entry” guards, containing boundary conditions for a function call. In our simple example the onlyOwner modifier on store (inherited from Ownable) instructs the EVM to check that only the “owner”, who initially is set to the contract creator inside the derived parent constructor call, may invoke the store function.

Once you’ve written a contract like that, you can compile it using a Solidity compiler, inside your IDE, using your favorite toolchain or just right inside Remix. A solidity compiler creates two important things: first, executable bytecode that can be interpreted by the EVM and, second, a so called Application Binary Interface (ABI) that contains a user- and machine readable definition of your contract’s public methods. You need the ABI, or parts of it, to instruct clients (e.g. your Web3 / Javascript Dapp), how to interact with a deployed instance of your contract code.

To actually deploy the contract, you send a large transaction containing its bytecode to an Ethereum network, including an appropriate amount of Gas (each contract deployment modifies the state of the blockchain just as every other writing transaction).

Once a block has been mined that contains the code, the contract will get an unique address that others can use as a transaction target. A contract actually behaves like an externally owned account, only that it doesn’t have its own private key. It can call other contracts (when triggered by an external transaction) and store monetary value (e.g. Ether) and data and will react to transactions of any account (contracts or EOAs) according to the rules that are set inside the contract’s code.

I deployed the storage example contract on the Kovan testnet, and you can checkout its code, the bytecode and its ABI here: https://kovan.etherscan.io/address/0x7DA77f8a834369dDc5e9e47407C9746Ed55C3b72#code. Etherscan is by far the most prominent platform to view onchain data. If you’re wondering how the source code ended up visible on it: Etherscan allows smart contract developers to upload their sources for an already deployed contract, verifies that it’s compiling to exact deployed bytecode and then displays it to all users. This process is called “validation” and eventually involves flattening your source code to one large file or using a tool that uploads all sources and dependencies at once, the most powerful of them being Sourcify.

If you consider interacting with the contract from within a Dapp, you’ll need the aforementioned ABI that’s generated during compilation. For our Storage contract it looks like this:

Libraries like ethers.js or web3.js usually wrap ABIs with a dynamic class. You can use it to transparently invoke contract methods using a connected contract instance in your client code. Client code that interacts with our contract could look like this:

Smart Contract Development Environments & SDKs

I already introduced you to one IDE that many developers use build smart contracts on the fly: Remix. It’s a great tool to get you started, comes with lots of plugins for virtually any contract related workflow, it has a decent user interface and is very well documented.

When you start building Dapps, it falls short though, because you’re going to have to integrate your contract code with your Dapp, share and update the ABIs inside your developer workflow or add backend code or CLI tools. There are two commonly used toolchains that allow you to build Ethereum based apps inside non trivial project repos: Hardhat (formerly Builder) and Truffle.

In a nutshell, both are great. Emotionally, hardhat is closer related to people who like the ethers.js library and truffle is closer to web3.js. Another difference is that Truffle comes with a contract based migration concept to deploy your contracts, whereas Hardhat lets you as a developer write scripts to get your contracts deployed. Hardhat shines with (in my opinion!) slightly better intuitive support for automated tests, full Typescript integration and autogeneration of boilerplate code for typesafe usage of smart contracts, made possible by a library called Typechain.

Other handy tools to have a look at to get started are Austin Thomas Griffith’s scaffold.eth, Paul Razvan Berg’s Create Eth App, and OneClickDapp that generates a Dapp out of a deployed contract codebase.

OpenZeppelin: audited smart contract primitives

Building a baby storage contract like the one shown above is the tiniest tip of the iceberg above what you can achieve with smart contracts. If you’re in the Ethereum space, you likely will have heard about the tokenization of things, about Defi protocols, yield farming, decentralized exchanges, NFTs, DAOs and alike. All those are blockchain applications, built on smart contracts. Many of them make use of some very basic primitives in the Ethereum space that are known by their respective EIP numbers: ERC20, ERC721 and ERC1155, which all are token standards.

Before you try to wrap your head around them yourself, rest assured: it’s nearly impossible to write safe code to implement even their most simple parts on your own. Hence nearly everyone uses a collection of base libraries to implement the most general use cases of smart contracts, and it’s called OpenZeppelin Contracts (OZ).

Besides token standards OZ has implementations for ownership and role based access, timelocks, counters, governance, contract proxies, enumerable mappings, introspection, math and string operations. They’re actually everywhere and I couldn’t encourage you more than to checkout them right now. Their documentation comes with lots of examples that made me understand tokens far better than any article could explain.

Contract Upgrades

You already might’ve wondered how you could update code on the blockchain once it has been deployed, for example if you found a bug . The short answer is: you cannot. That’s why most projects run through very thorough and costly auditing processes before they launch their contracts on mainnet. A tool that can find the most obvious issues in your code automatically is Remix’ static analyzer but rest assured: smart contract security is far harder to achieve than running a static code analysis tool on your code. Here are some articles that might give you a perspective of how hard it is to make EVM code bullet proof in practice.

A highly acclaimed feature that OpenZeppelin therefore has in stock are upgradeable contracts. Their name is slightly misleading since they’re still far from being upgradeable. Instead, they’re a pattern that makes use of some advanced Solidity internals to enable so called contract proxies.

In a nutshell the idea is to first deploy a contract proxy as well as a first implementation contract and tell the proxy to use that implementation. The proxy delegates all calls to the implementation contract, but all state changes (i.e. the storage) are persisted on the proxy’s address space itself. If you decide to “upgrade” your contract with new code, you’re actually deploying a full new implementation and point the proxy to it. There are some tradeoffs here, e.g. the replacement of constructors with initializing functions and a non updateable storage layout that effectively doesn’t let you update variable names and force you to extend your variable list, instead of being able to replace old variables.

Upgradeable contracts will increase your development speed and your beta releases but using them for contracts that lock millions of dollars might not be the best idea, depending how you look at their implications.

It’s a wrap 🌯!

There’s no way to put a TL/DR; under this article, but if I had to put it shortly: Blockchain development is not the easiest task, but honestly it isn’t that hard either. What is really hard to get right, is dealing with the dependencies between your Dapp packages. I’ve become a huge fan of pnpm powered monorepos for that job. Security is another deal breaker that I just briefly touched upon during the last sections of this article.

Now, I wish you the very best of luck in your endeavours in the smart contracts & Dapp space. If you’re interested in getting in touch with me or my company Turbine Kreuzberg to consult on contract development, web3 tech and decentralization, just drop us an email or DM me on Twitter.

The Last Introduction to Web3 / Ethereum For Developers was originally published in t14g on Medium, where people are continuing the conversation by highlighting and responding to this story.

Präludium

In den ersten beiden Quartalen 2021 war ich auf so vielen Raddemos, dass ich mich beinahe als Radaktivisten bezeichnen würde, nur dass sich meine Aktivität auf Anwesenheit beschränkt. Ich bin schon ziemlich rad-ikal, aber dennoch nicht Mitglied des ADFC (zu viele “Vogelfreunde” gehobenen Alters, dafür fühle ich mich zu jung, auch wenn ich es wahrlich nicht mehr bin), ich fahre als Rädchen im System mit und hoffe, mit meinem eigenen Verkehrsverhalten dazu beizutragen, meine Heimatstadt Berlin, unsere Region und natürlich den Planeten ein kleines bisschen besser zu machen. Dabei folge ich der Überzeugung, dass innerstädtischer motorisierter Verkehr minimiert werden muss, befürworte den Kfz-freien Innenstadtring und verfolge die Entwicklung nachhaltiger Mobilitätsangebote. Ich kann mich nicht mehr konkret an meine letzte Fahrt mit dem ÖPNV oder in einem Pkw erinnern; mein Auto habe ich 2019 abgeschafft, nachdem ein Rotabbieger mit seinem Kaffee-Dreirad auf der Reichenberger Straße meine Vorderachse so stark verbogen hat, dass die Reparatur den Zeitwert meines hochgeschätzten aber zuletzt kaum genutzten königsblauen Honda Civic überschritten hätte.

Vor diesem Hintergrund gibt es für mich eigentlich nur eine Art des wahren Urlaubs, und die findet auf dem Sattel statt. Was ich definitiv nicht bestreiten kann: mehrtägige Radtouren haben etwas mit Schmerzen und mit Verzicht zu tun. Es gibt Rennrad-Pros, die sich kegelförmige Satteltaschen mit 40l Stauraum bei Amazon bestellen und damit 180km an einem Tag abreißen. Das nennt sich Bikepacking und es hat seinen Reiz, weil sich der Windwiderstand mit so einem Päckchen unterm Hintern minimiert. Die längste Tour, die ich jemals gefahren bin, ging von Pasewalk bis Pobierowo in Polen und am Ende standen 150km auf dem Tacho. Kann man machen, aber man merkt es dann auch.

Wenn ich mit meinem Billo-Cyclocrosser der Noname-Eigenmarke “Carver” von Fahrrad XXL in aluminumgrau auf Reisen gehe, hänge ich aber ganz ordinäre graublaue Gepäckträgertaschen dran. Mit auf die Reise gehen ein Zelt für eine Person, Schlüppis, Söckchen und T-Shirts pro Tag, drei Radlerhosen, von denen ich eine, die teuerste, unterwegs gecrashed und in einem öffentlichen Mülleimer in Ueckermünde entsorgt habe, einer Jogginghose, die ich nicht brauchte, einem Hoodie, den ich gleich am zweiten Tag so vollgeschwitzt habe, dass er weiße Streifen bekam und nicht gut roch, 3 Ersatzschläuchen, die ich aus Erfahrung einsteckte aber entgegen der Erfahrung nicht brauchte sowie ein bisschen Kabelkrimskrams und ein aufblasbares Kopfkissen von Decathlon. Letzteres ist glaube ich das wichtigste Utensil von allen: weich, kuschelig und aufblasbar und ein wirklich guter Freund, wenn man nachts wegen der schnarchenden Zeltplatznachbarn, den Mückenstichen oder den Sattelwunden nicht schlafen kann und wahlweise in ein Kissen schreien oder heulen möchte.

Ich muss es einfach sagen, bevor hier ein falscher Eindruck entsteht: ich bin nicht als großer Camping-Freund auf die Welt gekommen, wurde nicht als solcher sozialisiert und bin eigentlich auch heute noch keiner. Ich war in meiner Kindheit nie campen und wusste bis zu meiner Lüneburger Bundeswehrzeit auch nicht wirklich, wie man ein Zelt aufbaut. Beim Bund habe ich vor gefühlt einhundert Jahren neben vielen anderen im zivilen Leben nicht anwendbaren Dingen gelernt, mit Situationen klarzukommen, die man selbst nicht kontrolliert. Wie man die mentale Vordergrundmusik leiser dreht, wenn gerade mal alles richtig Mist ist, wenn der Hügel kein Ende zu nehmen scheint, wenn es während des Ritts auf der Kopfsteinpflasterpiste anfängt zu regnen. Was der Bund einer Radreise diesbezüglich voraus hat: man ist stets mit 50 anderen Freunden, man nennt sie dort Kameraden, unterwegs, die gerade alle das selbe erleiden und sich gegenseitig aufbauen, eben weil sie gerade auch da sind.

Kennt Ihr dieses Gefühl, auf einem emotionalen Drahtseil zu stehen, wenn die äußeren Umstände gerade über einen hereinbrechen? Ich glaube mittlerweile, das wahre Ziel von mehrtägigen Radtouren, die man alleine bewältigt, besteht darin, solche Situationen anzunehmen, durchzustehen und hinterher mental gestärkt aus ihnen hervorzugehen. Und da die Erinnerungen gerade noch frisch sind: mit Kindern im Gepäck geht das natürlich auch ganz wunderbar. Nur dass man die Kinder nicht auf dem Zeltplatz entsorgen kann, wenns einfach zu viel wird und man beschließt, doch abzubrechen und mit der Bahn nach Hause zu fahren. Halleluja, liebe Eltern, Ihr macht einen krassen Job und ich anerkenne Eure mentale Stärke! Ich habe auf meiner Tour Eltern und Familien, Opas, Omas, Tanten und Onkel beobachtet und mitleidig zugezwinkert, die von Säuglingen bis zu Zwanzigjährigen alles dabei hatten, was man als Mensch so produzieren kann. Die wenigsten von ihnen waren allerdings mit Fahrrädern unterwegs.

Ja klar, sagt Ihr, so bekloppt sind die ja auch wieder nicht! Aber einige, Ihr werdet es nicht glauben, die sind so bekloppt! Verpacken Vorschulkinder in einen Anhänger oder ein Lastenradkörbchen und ballern damit über unbefestigte Feldwege. Das passt ein bisschen ins Bild, das ich hier malen möchte: man braucht ganz offensichtlich keinen SUV mit hunderten PS und einen gewaltigen Hänger mit Vorzelt, den man hinter sich herzieht, um ihn dann vier Wochen lang auf einem Campinglatz abzustellen, nur um seinem Nachwuchs das Konzept “Leben in der Natur” zu demonstrieren.

So toll wie kleine Kinder Panzerfahrzeuge (ja, da war er wieder, der Bund, aber das ist wirklich eine andere Geschichte) finden mögen: Fahrräder sind für sie genauso toll! Und warum das so ist, sollte jedem klar sein, der eins fährt. Man soll ja keine ungeprüften Zitate aus dem Internet übernehmen, aber dieses von John F. Kennedy habe ich schon so oft gesehen, dass ich es für verbürgt halte:

Nichts ist vergleichbar mit der einfachen Freude, Rad zu fahren.

Jetzt aber wirklich zu meinem Reisebericht!

Tag 1 Berlin Neukölln — Fürstenberg

Nordneukölln gehört vermutlich zu den zugleich beknacktesten und liebenswürdigsten Orten, an denen man überhaupt wohnen kann. Überall durchgeknallte Hipster-Touristen, die jede Goa-Party mitnehmen, die in den illegalen Airbnbs so stattfinden, Fixer, die in die Hauseingänge koten, fette Mercedeskarossen, die jede Nacht (wirklich: jede Nacht, liebe Ordnungshüter!) die Ansaugstöpsel auf dem Kotti knallen lassen und jede Menge freundlich grüßende Schwarzafrikaner, die gut gelaunt ihre Runden durch den Görli drehen. Und dann: ein Gourmet-Highlight nach dem anderen, spontane Straßenparties, Kreative und Künstler, wohin man schaut, ein Lebensgefühl, so lässig, dass der Venice-Beach dagegen aussieht wie ein Ikea-Bällebad. Laut, schrill, impulsiv und äußerst inspirierend. Aber wenn man jede Sommernacht hier bei geöffnetem Fenster schlafen muss, dann ziehts einen unweigerlich ins Grüne.

Fürstenberg und ich haben eine gemeinsame Historie, die mit meinem wirklich sehr alten (bezogen auf die Dauer unserer Bekanntschaft) Freund Bastian zusammenhängt. Irgendwann kamen wir beide mal auf die Idee, mit dem Fahrrad nach Himmelpfort zu fahren, weil da der Weihnachtsmann wohnt. Bastian ist schon mal den Berlin Marathon gelaufen und fährt mit dem Rad von Spandau ins Büro nach Halensee, aber die Langstrecke auf zwei Reifen ist (noch) nicht so ganz seins. Ab Kilometer 70 ging ihm echt die Puste aus; mir gings nicht viel besser, aber ihm wars eher anzumerken.

Jetzt wollte ich wissen, ob ich in der Zwischenzeit besser geworden bin. Also sattelte ich Montag morgen entspannt auf und fuhr durch den Berliner Stadtverkehr gen Norden. Die Autofahrer in Berlin haben wir mittlerweile dank vieler Demos, Critical Masses, Popup-Radwegen und der Fahrradstaffel der Polizei nach meinem Dafürhalten ganz gut daran gewöhnt, dass Verkehrsteilnehmer auf zwei Rädern als Verkehr und nicht als anzuhupendes Hindernis gelten. Bis zu dem kleinen Vorort Summt kurz über der A10, den man übrigens wahlweise als SUV-Parkplatz oder Golf-Oase bezeichnen kann, gabs dann auch keinerlei nennenswerten Vorkommnisse. Von Summt an gehts auf der Landstraße weiter und Brandenburger Autofahrer, gerade die Auto fahren als Beruf ausüben, sind noch nicht so gut in der StVO geschult wie ihre Berliner Kollegen. Nicht, dass mich jemand vom Pferd geholt hätte, aber mit den gesetzmäßig festgelegten 2m Mindestabstand außerorts überholt auf Brandenburger Landstraßen definitiv nicht jeder.

From Kreuzberg to Fürstenberg/Havel | Rennrad-Tour | Komoot

Kein Wunder, dass am Rande dieser “L21” genannten Strecke große Plakate und manche Demos darauf aufmerksam machen, dass hier ein Radweg hingehört. Tatsächlich ist die Straße aber glatt, gut asphaltiert und führt durch ein Waldgebiet — zum ersten Mal war also Durchatmen angesagt. Richtig schön wirds ab Zehlendorf (der Ort, nicht der Bezirk), wenn man sich langsam dem Oder-Havel-Kanal nähert. Dort ging mir nach 40km auch erstmals die Puste aus. Ich hielt an einem kleinen Hofladen, der noch nicht geöffnet hatte, setzte mich auf eine tausend Jahre alte Bank, grüßte den Schweinebauern auf seinem Traktor und beobachtete Störche, die auf einer Wiese nach Fröschen oder Staniolpapier pickten.

Bei Liebenwalde vereinigt sich der Radweg dann mit dem Berlin-Kopenhagen Radwanderweg, der definitiv die bessere Wahl für eine Tour von Berlin an die See ist, aber für einen Neuköllner einen ganz schönen Umweg bedeuten würde. Dort trifft er auf den Voßkanal, den Haupstrom der Havel, und begleitet ihn bis nach Zehdenick, einem der größten Orte auf dem Weg nach Fürstenberg. Mal ein fettes Kudos an den Erfinder des Straßenbelags dort: grob gekörnt und leicht kieselig blendet er die meisten Wurzeln aus und lässt einen locker mit einem 30er Schnitt die Kilometer vergessen. Damit überholt man nicht nur alle Elektroradler, die antiproportional zu ihrem Alter ohnehin nie an ihr 25er-Limit stoßen, sondern auch die Flöße und gedrosselten Motorkähne, die gen Norden dümpeln.

Dafür, dass Zehdenick auf der Karte ziemlich groß aussieht und auf einer europäischen Radroute liegt, ist er ausgesprochen unspektakulär. Ein Baumarkt, zwei Supermärkte, eine historische Zugbrücke aus Holz und eine kulinarische Katastrophe erwarten Radfahrer hier. Am leblosen zentralen Rathausplatz erwarteten mich die letzten Zurückgelassenen des Sozialismus am lokalen Imbiss, der einzigen mir bekannten geöffneten Gastronomie in diesem gottverlassenen Ort. Zwangsläufig gönnte ich mir dort zwei Radler und ein Stück Pappe, das als Schnitzel Wiener Art auf der Karte stand.

Eines sei an dieser Stelle bereits verraten: Belastbares Material für einen kulinarischen Reiseführer konnte ich auf dieser Rundfahrt beim besten Willen nicht sammeln. Entweder war ich zu blöd oder zu blind, aber viel wahrscheinlicher ist: in der ehemaligen sowjetischen Besatzungszone gilt es auch heute noch entweder als unfein oder als übertrieben, sich zum Essen in einem Restaurant einzufinden, in dem die Stühle Sitzbezüge tragen. Nein, das liegt ganz sicher auch an dem fiesen Corona-Virus und vermutlich gehe ich gerade zu hart mit der Kulinarik des Ostens ins Gericht. Und bitte vergesst nicht: dies ist mein persönliches Logbuch und falls Ihr anderer Meinung seid, oder wisst, wo sich in Zehdenick oder anderswo die fetten Schnitzel oder Sushi-Rollen tummeln, schreibts in die Kommentare.

An den Abschnitt zwischen Zehdenick und Dannenwalde kann ich mich beim besten Willen nicht mehr bildhaft erinnern, wohl aber an meine Entscheidung (erkennbar an der kleinen Beule auf der Karte bei km 78,6), die von Komoot vorgeschlagene Bundesschnellstraße nach Fürstenberg zu meiden. Schon beim Ortseingang donnerte mir ein LKW nach dem anderen am Lenker vorbei und daher dachte ich, es sei eine gute Idee, die 7km Umweg über Bredereiche in Kauf zu nehmen. Und das führt uns zur ersten Regel, die Ihr bitte immer beherzigen solltet: Wenn ihr mit einem rennradähnlichen Gefährt unterwegs seid, und Komoot bittet, eine rennradtaugliche Route zu errechnen, dann glaubt Komoot, dass es die beste Route ausgerechnet hat. Nicht nur, dass der Straßenbelag in dieser Region zu weiten Teilen ziemlich dürftig ausfällt, der Weg führt auch über den einen oder anderen Hügel und hat mich in Summe sicherlich 50 unnütze Höhenmeter gekostet. Klingt alles nicht viel, aber nach 80km Fahrt mit Gepäck merkt man auch jede noch so kleine Steigung unmittelbar in den Beinen. In steiler Schussfahrt stieg ich zuletzt bis Fürstenberg ab, und landete schließlich bei meinem Tageseziel: dem Campingplatz Wilde Heimat.

Mich empfing eine ausgesprochen nette Dame, die kulturell irgendwo zwischen der Republik Freies Wendland und einer Yoga-Matte sozialisiert wurde. Wie der Name des Platzes vermuten lässt, bewegen sich hier die Formalien in der Nähe des Nullpunkts, sodass ich mir in Rekordzeit einen Zeltplatz suchen konnte. Besonders nett: die Zeltwiese ist von Baby-Kiefern durchsetzt, die Sicht- und Schallschutz bieten. Ganz so wild wie der Name vermuten lässt, gehts hier aber nicht zu. Die üblichen Fahrgaragen-Camper und Offroad-Boliden stehen auch hier auf der Fläche, aber man hat schon den Eindruck, mit ein paar Wilden auf einen Haufen geworfen worden zu sein. Das merkt man auch an der Kinderdichte: die ist natürlich zur Ferienzeit auf jedem Campingplatz hoch, aber hier hatte man den Eindruck, dass alle Kinder so wild sein konnten, wie sie wollten. Mädchen hingen in von Bäumen herabgelassenen Spanngurten, ein paar Halbstarke zersägten einen Baumkadaver zu Brennholz fürs gemeinschaftliche Lagerfeuer, die pubertäre Platzelite versammelte sich an der überdachten Sommerküche, die auf einem verlassenen Bahngleis steht und kleine Familien versuchten erfolglos ihren Kleinkindern beizubringen, dass man nicht mit Schuhen ins Wasser geht.

Ich habe mit Kindern zugegebenermaßen nicht allzu viel am Hut und wir gehen uns in der Regel gekonnt aus dem Weg, umso erstaunter war ich, als ein Junge auf mich zugerannt kam und mich ohne Hallo oder Guten Abend nach dem Weg zum Wasser fragte; da ich auch gerade erst eingetroffen war, konnte ich ihm auch nicht weiter helfen, als eine Richtung zu raten (die sich wie immer als falsch herausstellte). Später traf ich ihn 50 Meter weiter am Ufer mit seinem Kumpel Mücken jagen. Meine Zeltnachbarn waren Simon (30) und Valentin (5) aus Bremen, die vor Simons Ex ins wilde Brandenburg geflüchtet waren, und solange Verstecken spielte, bis Valentin auf einen Erdnagel (in Zivilsprech: Hering) trat und ich kurz davor war, dem Jungen aus Mitleid das Bein zu amputieren. In solchen Momenten lohnt es sich, die sanitären Anlagen aufzusuchen. Gemäß deren Beschreibung auf der Wilde-Heimat-Webseite befürchtete ich das Schlimmste, wurde aber äußerst positiv überrascht: Einzelkabinen und keine Nerverei mit 3-Minuten-Duschmarken sowie ein supersauberes Sani-Gebäude haben alle meine Befürchtungen ins Gegenteil verkehrt.

Ich drehte anschließend noch eine Runde durch Fürstenberg, um Italiener, Griechen oder, Gott steh mir bei, einen Inder zu finden, aber ich fand nur Netto, den mit dem Scotty. Ein Portiönchen frische Ananas, eine Buttermilch mit Erdbeeraroma, eine Packung Kekse und eine Flasche Cola mussten als Abendessen herhalten. Gesund ist das nicht, aber ich habe festgestellt, dass Milchgetränke nach langen Radtouren die Lebensgeister wiedererwecken und die brauchte ich, denn kaum lag ich in meinem Zelt, breitete sich ein wirklich fieser Krampf durch meinen rechten Oberschenkel aus. Kurzzeitig überlegte ich noch, ob ich Valentin fragen solle, mir eventuell das Bein zu amputieren, aber nach zehn Minuten war das Schlimmste vorüber. Das war der Moment, in dem ich beschloss, beim nächsten Netto nach Magnesiumtabletten zu suchen und meine Bewegungen beim Einstieg in den Schlafsack besser zu koordinieren.

Tag 2 Fürstenberg — Prenzlau

Die erste Nacht im Zelt ist für einen Nordneuköllner durchaus gewöhnungsbedürftig. Statt betrunkener Briten schreit immer irgendwo ein Kind oder ein Kranich. Ich kam dennoch bei Sonnenaufgang gegen 5 Uhr irgendwie zu mir, blieb noch drei Stunden wie ein Stein liegen und lauschte dem obligatorischen Reißverschlussgezerre. Übrigens: wer sein gesamtes Camping-Wissen auf Festivals erlernt hat, wird sich wundern, dass nicht ständig jemand Helga ruft oder betrunken über ein fremdes Zelt stolpert; solches Benehmen ist mir auf keinem Campingplatz jemals aufgefallen.

From Fürstenberg/Havel to Prenzlau | Rennrad-Tour | Komoot

Ohne Frühstück brach ich auf, nur um am Ortseingang von Fürstenberg nochmal anzuhalten und die erste Zigarette des Tages zu rauchen. Das habe ich ja noch gar nicht erwähnt: ja, ich rauche gern, ich rauche viel zu viel und ich werde mit ziemlicher Sicherheit auch daran sterben, und ja, ich weiß, dass das vermutlich kein schöner Tod werden wird, aber dafür hab ich ja Euch, die Ihr danach darüber berichten und Eure Kinder belehren könnt. Wie immer spielte das Schicksal mit und schickte mir alsbald einen Raucherfreund, der auf einem kleinen Elektrorollstuhl hinter mir auftauchte, mein Gepäck bestaunte und fragte, wo die Reise hinginge. An die Ostsee, sagte ich. Ach das ist ja ganz schön weit, sagte er. Er sei 86 Jahre und früher Bauer gewesen und an seinem Rollstuhl hingen wie zur Mahnung 3 Sauerstoffflaschen, die ihn am Leben hielten. Ich sagte: erfüllen Sie sich jedes Jahr einen Traum, dann werden Sie sicherlich noch 100 und dachte dann: wahrscheinlich ende ich genau so. Aber unter uns: Der Mann verbringt seinen Lebensabend auf einem fahrbaren Untersatz, hat permanent gute Laune und ein Dauerabo Sauerstoff, so schlimm klingt das für mich jetzt auch wieder nicht.

Für diese Etappe verletzte ich wieder bewusst Regel Nummer Eins, diesmal doppelt-bekloppterweise aber sogar bei der Planung. Ich dachte mir, die direkte Strecke von Fürstenberg nach Prenzlau sei ein bisschen zu banal und daher baute ich eine kleine Komplikation in die Route ein, die mich durch das vermeintlich schöne Waldgebiet der Feldberger Seenlandschaft führen würde. Bis nach Lychen folgte ich der weniger stark befahrenen Bundesstraße, auf der mir auch einige Rennradler entgegenkamen. Kurz vor Lychen nahm ich mein Frühstück in Form eines kleinen, zerdrückten, in einer Plätzchenform gebackenen Rühreibrötchens vom Lila Bäcker zu mir und merkte, dass Komoot mich nicht durch Lychen, sondern wegen meines Detour-Wunsches nördlich daran vorbei führte (Kilometer 13). Zwischen Lychen und Feldberg war das auch eine großartige Entscheidung: am Anfang eine malerische Wasserlandschaft, dann kleine Dörfer, viel Horizont, wenig Menschen, meistens Asphalt.

Das ging solange gut, bis ich bei Kilometer 37 auf die von mir gewählte Komplikation stieß: eine kleine Anhöhe ohne Radweg, an deren Rändern Obstbäume wuchsen und Schafe grasten. Ein plötzlicher Regenschauer nötigte mich dazu, in einem Quittenhain Unterschlupf zu suchen (dort entstand das Fahrradfoto) und anschließend nochmal hinaufzusteigen und ein Panorama von der Umgebung aufzunehmen.

Ab dem Quittenhain kam mir der Weg bereits suspekt vor: er existierte genau genommen überhaupt nicht mehr. Nicht ahnend, was mich nun erwartete, schob ich mein Rad (samt Gepäck) tiefer in den Wald hinein und merkte, dass hier allenfalls gestandene Offroader und Downhill-Fahrer Freude am Fahren entwickeln können.

Fast drei Kilometer schob ich mein Gefährt durch den Wald, Steilhänge hinauf, Brennessel-Schluchten hinab und erlebte hier einen dieser eingangs beschworenen Momente: Man will eigentlich nur noch aufgeben, das Rad von der Klippe werfen und ein Taxi rufen. Aber das geht ohne Empfang ja schlecht, also schleppt man sich weiter. Viel besser wurde der Weg auch nach dem Höllenwald nicht: Schotterpisten und abgenagtes Kopfsteinpflaster wechseln sich hier ab. Dank Cyclocross-Bereifung und ein bisschen Erfahrung konnte ich den letzten Hang immerhin schneller nehmen als zwei breitreifig vollgefederte Mountainbiker, die ich im Vorbeirollen freundlich grüßte, aber ein Genuss ist so eine Abfahrt mit Gepäcktaschen keinsfalls.

Ein bisschen blohnt wurde ich bei Kilometer 41,5: am Lichtenberger Strand gibt es eine malerische Froschperspektive auf den Wald des Todes, den ich nur eine halbe Stunde zuvor fluchend durchstreifte.

Dort traf ich auch auf ein Verkehrsmittel, das für die soeben gemeisterte Tortur weitaus besser geeignet gewesen wäre: eine Gruppe Reiter vertrat sich gerade die Beine und ich versuchte mich erfolglos, mit ihren Pferden anzufreunden. Das ist bei mir ähnlich wie mit Kindern und Rust-Programmierern: ich mag Pferde, aber sie mögen mich in aller Regel nicht. Wer hier noch mitliest und mir einen Urlaub anbieten möchte, bei dem ich ein bisschen Reiten lernen kann, bitte schreibt mir!

Der weitere Verlauf der zweiten Etappe verlief dann zum Glück reichlich ereignislos, führte mich aber über unerwartet viele geographische Höhen, Tiefen und Orte, die wie alternde deutsche Rockstars oder weitere Berliner Bezirke klingen sowie an Windparks vorbei, die man logischerweise dort errichtet, wo auch eine Menge Wind bläst.

Die Einfahrt nach Prenzlau nach 70 Kilometern beginnt dann wieder außerordentlich enttäuschend: ein ehemals großes griechisches Restaurant am Ortseingang (Hellas) hat geschlossen. Der Weg in die Innenstadt ist ein Nadelöhr für LKWs und Kraftverkehr, Radfahrer werden auf das nebenliegende, benutzungspflichtige, horizontal wie vertikal wellenförmig angelegte Imitat eines Radwegs verdrängt, bis man plötzlich auf den Nordzipfel des Sees trifft, wegen dem ich mir Prenzlau als Etappenziel aussuchte: der Unteruckersee! Der Name ist nicht nur drollig, sondern für eine Person mit technischer Weltsicht auch lagemäßig falsch: geographisch liegt der Unteruckersee nämlich über dem Oberuckersee, an dessen Ufer ich vor zwei Jahren übernachtete. Seinen Namen verdankt er natürlich der Tatsache, dass er aus Sicht des Flusslaufs der Ucker hinten liegt.

Bevor ich die letzten paar Meter zum Campinglatz zurücklegte, setzte ich mich neben eine Gruppe älterer Damen auf eine von der Europäischen Union gestiftete Sitzgruppe und genoss die Aussicht. Ich war vorher schon ein paar Mal auf Tagestouren in Prenzlau angekommen und bin jedes Mal überwältigt von der Schönheit der Nordostseite des Sees. Sie ließ mich auch fast darüber hinwegsehen, dass der finale Anstieg zum Viersterne-Campingplatz “Sonnenkap” über eine 300m lange Kopfsteinpflasterpiste führt. Man kann sie als Radler zwar umfahren, aber das fand ich erst am folgenden Tag heraus.

Wer normalerweise nur in Hotels nächtigt, dem sei gesagt, dass es tatsächlich Sternekategorien für Campingplätze gibt. Das Sonnenkap gehört zur gehobenen Klasse, was sich durch ein moderneres Sanigebäude, grünerem Rasen sowie irgendein Lage-Highlight auszeichnet: hier ist es der direkte Zugang zum See, den ich, nachdem ich mein Zelt auf einer bereits gut gefüllten Zeltwiese aufgebaut hatte, sofort zu nutzen wusste. Das Wasser des Unteruckersees ist glasklar, das Ufer fällt ganz sanft ab und besteht aus reinem, weichen Zuckersand: man läuft wie durch kühle Watte in den See hinein.

Eine Dusche später nahm ich mir vor, die Innenstadt von Prenzlau zu erkunden und erlag erneut der Hoffnung, eine Gastronomie zu finden, die etwas kulinarisch erinnerungswürdiges zustandebringen könnte. Um vom See in die Stadt zu gelangen, muss man stets einen kleinen Anstieg bewältigen, aber ohne Gepäck fährt sich mein Fahrrad fast wie von alleine. Das vielversprechendste Restaurant “Zum Schwan” sah mir nach einer Touristenfalle aus, also steuerte ich nach einer Maps-Konsultation den nächsten Griechen an. Der muss seinen ökonomischen Master in der Baumschule gemacht haben, denn er hat beschlossen, in der Hauptferienzeit selbst Ferien zu machen. Ob der Italiener mehr von touristischer Wohlfahrt versteht, kann ich ebenfalls nicht behaupten, denn der hat Dienstags Ruhetag. Nach einer ganzen Stadtumrundung fuhr ich also frustriert zurück zum Schwan und bestellte aus Trotz ein Gyrosgericht, das zwar bei weitem nicht an das Kreuzberger Original heranreicht, aber definitiv Spuren von vormals lebendigen Tieren zu enthalten schien.

Zwei Radler und die entsprechende Bettschwere später beschloss ich, noch Proviant für den kommenden Tag aufzunehmen und besuchte den örtlichen Rewe. Auf dem Weg dorthin passierte mich ein Grüppchen alkoholbedingt gut gelaunter, sehr dunkelhäutiger Prenzlauer, dessen Anführer es für lustig befand, eine rote Fußgängerampel zu überqueren. Ich folgte ihnen mit leichtem Abstand, konnte aber den rassistischen Kommentar eines bioprenzlauerischen Stammgastes des vorgelagerten Rewe-Imbisses nicht überhören: “Noch nichtmal sechs, und die Ratten sind schon besoffen”. Solche Kommentare machen mich nicht nur traurig, sie machen mich wütend und ich muss es in dieser entschiedenen Klarheit sagen: rassistische Kackscheiße gehört auf den Scheiterhaufen deutscher Geschichte. Aber ich finde es auch wirklich nicht besonders vorausschauend von einer Person mit neuweltlich-jamaikanischem Phänotyp, die ortsbekannten Altnazis mit beschwipster “Ich scheiß auf Eure Gesetze”-Laune dazu zu provozieren. Kopfschüttelnd betrat ich den Rewe und besorgte mir Magnesiumtabletten und Schokonüsschen.

Auf dem Heimweg legte ich an einer kleinen Halbinsel einen Zwischenstopp ein, um die Golden Hour zu genießen und eine Weile die prominenteste Parkbank der Dorfjugend zu blockieren. Dabei wurde ich Zeuge eines Drachenboottrainings, in dem die Führerin des Bootes von Zehn auf Null zählte und dann ihre Mannschaft mit übermenschlicher Motiviation begann, ins Wasser zu stechen: bleibende Eindrücke zwischen Wikingerkultur und olympischem Geist.

Die meisten Campingplätze haben irgendeinen Haken. Selten einen wirklich dramatischen, aber das Sonnenkap hat trotz vieler bedeutender Annehmlichkeiten einen großen: Es liegt direkt neben der Regionalbahnlinie, auf der bis um ein Uhr in der Nacht quietschende Bahnen in die Stadt rumpeln. Dennoch war die Nacht zumindest in der Nachbetrachtung besser als die erste und ich fand genügend Schlaf, um mich von den Brennessel-Strapazen, der Schieberei und den Kommentaren widerlicher Dorfnazis zu erholen.

Tag 3 & 4 Prenzlau — Bellin

Nach einem kurzen Frühstück an der bekannten malerischen Halbinsel startete ich die mit etwas über 50km vermeintlich kürzeste Etappe meiner Rundreise. Mein Ziel, das Haffdorf Bellin, das einen Katzensprung von der Hafenstadt Ueckermünde entfernt liegt, hatte ich schon vor zwei Jahren entdeckt und alleine sein Name zwingt mich geradezu, ihm regelmäßig einen Besuch abzustatten.

From Prenzlau to Bellin | Rennrad-Tour | Komoot

Die Fahrt von Prenzlau startet mit ein paar verlassenen und vergessenen Dörfern, führt vorbei an Windparks und über die eine oder andere Steigung, die alle für sich genommen nicht weiter wild sind, in ihrer Summe aber zur muskulären Geduldsprobe werden. Hier überquert man auch die unsichtbare Grenze zwischen Brandenburg und Mecklenburg-Vorpommern, was für ungeübte Besucher eigentlich nur daran erkennbar wird, dass sich die hässlichen Gesichter der CDU- und AfD-Kandidaten auf ihren saudummen Wahlplakaten abwechseln; Favorit irgendwo zwischen “Berlin macht mehr Mist als unser Vieh”, “Eine Grenze ist da, um beschützt zu werden” und “Landschaft statt Windparks”. Dass man im Osten unserer Republik tatsächlich mit dem Schutz von Grenzen Wahlwerbung machen kann, finde ich in Ermangelung besserer Worte nicht nur geschmacklos, sondern bis ins Mark erschütternd.

Das erste Zwischenziel ist das kleine Städtchen Pasewalk, das zu den hässlichsten zählt, die ich auf dieser Tour erleben durfte. Einmal abgesehen von grauen, zerfledderten Bürgersteigen ohne Radnutzungspflicht, die noch Walter Ulbricht bewilligt haben dürfte, habe ich in Pasewalk wirklich nichts entdeckt, was eines positiven Kommentars bedürfte. Ein dicker weißen Mann am Steuer eines blauen Fords mit Anklamer Kennzeichen befand es für hilfreich, mich mit seiner Hupe darauf hinzuweisen, dass ich nach seinem Ermessen ungebührlichen Gebrauch der Fahrbahn mache. Das war aber zum Glück der einzige Bekloppte, der sich dazu angesichts meines Gefährts auf der ganzen Tour hat hinreißen lassen.

Obwohl Pasewalk zu den Städten gehört, um die man nicht nur als Radler besser einen Bogen macht, muss man ja irgendwann verpflegen und mangels jeglicher Alternative entschied ich mich für ein paar Geflügelwiener vom zentralen Norma, der es wie viele andere nicht für notwendig hält, seine Radparksituation der aktuellen Radverkehrssituation anzupassen. Als ich mein Fahrrad daher wie immer an einem Stahlpfosten am Rand des Autoparkplatzes befestigte, erntete ich dafür die üblichen bösen Blicke der AfD-Vorstandsdoubles und wusste unmittelbar, dass Verrückte wie ich in ihrer kleinen kaputten Welt absolut nicht willkommen sind. Die Idee, ein pseudonahrhaftes Brötchen beim lokalen Norma-Bäcker mitzunehmen, gipfelte mangels Auswahl nur in einem süßen Spritzkuchen.

In eine Mischung aus leichter Frustration und Belustigung ob des Schauspiels, dessen Zeuge ich in diesem schrecklichen Ort wurde, entschied ich mich, wenigstens nach einem hübschen Fleckchen Erde zu suchen, an dem ich in Ruhe meine Würstchen mit Süßgebäck zu mir nehmen musste. Ich fand es bei km 28.4, am Rande einer zugewachsenen Industriebrache und Totholzabladestelle. Angesichts meiner mentalen Verfassung möge man mir verzeihen, dass ich dort auch zum ersten und letzten Mal auf dieser Tour ein Fläschchen Magenbitter hinunterkippte, um meinen Geist halbwegs von dieser Katastrophe eines Ortes zu reinigen.

Die Rückker auf den Radwanderweg entschädigte aber für die kulturelle Folter der vergangenen halben Stunde: nördlich von Pasewalk scheint der örtlichen Verwaltung aufgefallen zu sein, dass sie die Zielgerade auf dem Weg an die Küste markieren und so haben sie einen durchgängig gut befahrbaren, nur unregelmäßig von Wurzeln durchstoßenen Asphaltweg neben die Bundesstraße gelegt, auf dem man schnell vorankommt. Das Örtchen mit dem illustren Namen “Viereck” hat zwar beschlossen, den Radreiseverkehr mit einer traditionellen Kopfsteinpflasterung auszubremsen, aber das konnte ich einem vergessenen Dorf mit extra bescheuertem Namen, das die Besserverdienenden der Region für sich entdeckt haben, gerade noch verzeihen.

Ab Viereck schlängelt sich der Radweg 20km bis zur Haffküste durch Kiefernwälder und ist beiderseits von Schildern mit militärischen Sicherheitshinweisen gesäumt; er führt durch zwei große Übungsplätze der lokalen Panzergrenadiere. Marder, Fenneks oder Luchse habe ich leider keine gesehen, dafür aber ein paar ziemlich futurustisch ausgestattete Mähdrescher, die mit Halbkettenantrieb über die Bundesstraße ratterten. Die Kadenz der Radfahrenden mit Kindern, Anhängern und Hunden nimmt auf diesem Abschnitt beträchtlich zu und kurz vor Eggesin setzte sich eine Elektroradlerin mit voller Unterstützung vor mich, der ich bis zur Dorfkirche des Ortes folgen konnte. Dort musste ich ein Viertelstündchen pausieren, und habe genervt den ununterbrochenen Lieferverkehr verfolgt, der sich durch das kleine Dorf quält, während ich meinee Extraration Magnesium wegnuckelte.

In Mecklenburg-Vorpommern gelten härtere Corona-Gesetze bei der Beherbung von Tagesgästen. Sie sehen vor, dass man nur mit einem tagesaktuellen Test auf einem Campingplatz einchecken darf. Daher stellte ich das Tagesziel auf das große, unter anderem für Touristen bereitgehaltene Testzentrum zwischen Feuerwache und Omnibusbahnhof in Ueckermünde ein. Als ich dort ankam, stellte sich heraus, dass es aufgrund einer “technischen Problemen” an diesem Tage geschlossen war.

Mit einem eher unguten Gefühl machte ich mich also erstmal auf den Weg zur letzten Fischbude am Hafen (Rosi’s Fisch-Oase <- beachtet die Kommentare :D) um bei Radler, Aal und Bremer darüber zu sinnieren, wo man in einer 1000-Seelen-Gemeinde wie Ueckermünde alternativ einen Test herbekommt. Die Dame am Tresen verwies mich auf ein Zentrum “gegenüber vom Rossman”, das bei genauerer Betrachtung nicht wirklich gegenüber vom Rossmann liegt, aber das ich nach einer vollständigen Sondierung der Innenstadt, durch die sich starker SUV- und Cabrio-Verkehr hupend und ohne Rücksicht auf fußgängerische Verluste seinen Weg durch die engen mit Kopfsteinen gepflasterten Gassen der Hafenstadt bahnt, schließlich doch noch fand. Das niederschmetternde Ergebnis: dieses Testzentrum hatte an jenem Tag permanent geschlossen.

Da ich von meinen vorherigen Besuchen in Ueckermünde wusste, dass der beste Weg zu meinem eigentlichen Ziel, dem Campingplatz in Bellin, nicht entlang der Hauptstraße, sondern am Haff entlang führt, radelte ich die knapp 1km lange, von mit Motorsägen aus Bäumen herausgeschnitzten Märchenfiguren gesäumte Strandallee hinunter und traf zum ersten Mal auf dieser Tour auf das Meer. Wobei der Begriff das Stettiner Haff natürlich etwas großzügig interpretiert: es ist eine Art verirrter Nebenarm der Ostsee und man kann mit bloßem Auge Kamminke auf Usedom erkennen, aber wenn man sich in den weichen Sand legt, die Augen schließt und dem Wellenrauschen zuhört, ist der Unterschied zu Scharbeutz fast nicht zu merken.

Zwei Kurven weiter erreichte ich schließlich den “Ferienpark Ueckermünde-Bellin” und wurde seinem freundlichen Besitzer vorstellig, der immer, wenn ich an der Registrierung stehe, in einen so breiten DDR-Dialekt verfällt, dass ich als Westberliner ihn mehrmals um Wiederholung bitten muss — das ist mir sonst eigentlich nur in Wien passiert. Der Extrakt der Konversation: ohne Test komm ich nicht auf den Platz, das Gesundheitsamt war vor zwei Tagen da und drohte ihm, den Laden dichtzumachen, wenn er nicht überall Abstandsschilder aufstellt, jedes zweite Waschbecken abklebt und Testungen seiner Gäste rigoros überprüft. Ich bin in solchen Situationen ein äußerst kooperativer und leidensfähiger Zeitgenosse und in Ermangelung von Alternativen blieb mir eh nichts anderes übrig, als mich dem Schicksal zu stellen, das mich nun erwartete. Kollege Platzwart setzte alle Hebel in Bewegung, dass das alternative Testzentrum in Eggesin (da kam ich her), nochmal ausnahmsweise seine Pforten für mich öffnete und versprach mir, in der Zwischenzeit den Verantwortlichen der Gemeinde ausfindig zu machen, den ich für diese zusätzlichen 20km teeren und federn könne. Er und Google Maps empfahlen mir, den kürzesten Weg nach Eggesin zu wählen, der durch einen sehr hübschen, von Rehen, Wölfen und Wildschweinen bevölkerten Wald führte. Mit Cyclocross-Bereifung kommt man die erste Hälfte ganz gut dadurch, aber dann folgt ein Abschnitt aus reinstem Zuckersand, der meinen Oberschenkeln und meinem mentalen Sicherungskasten für diesen Tag den Rest gab.

Verschwitzt und verstaubt stand ich eine halbe Stunde später vor “Schwester Anja”, der scheinbar letzten arbeitenden Person des Hospiz Vergissmeinnicht, einem ruhig gelegenen letzten Heim für schwerstkranke oder sterbende Menschen. Ich war der einzige “Kunde” in der Einrichtung, die planerisch für einen deutlich größeren Ansturm von zu Testenden ausgelegt ist und fühlte mich ein bisschen fehl am Platz. Schwester Anja bohrte ein bisschen in meinem Gehirn herum und eine Viertelstunde später bekam ich mein amtliches, kostenloses, negatives Testergebnis, ausgestellt auf einem Blatt Papier mit offiziellem Stempel. In der Nachbetrachtung habe ich dem Einsatz von Schwester Anja den Rest meiner Tour zu verdanken und daher entschloss ich mich soeben, 150€ an das Blaue Kreuz Eggesin zu spenden.

Auf dem Rückweg fiel ich nicht auf die Treibsandfalle des Waldgebiets herein, sondern wählte den langen Weg; erstaunlich, dass sich Wege doppelt so lang anfühlen, wenn man sie am selben Tag schon einmal bestritten hat, aber eine halbe Stunde später stand ich wieder an der Rezeption und konnte endlich einchecken.

Das Highlight dieses kleinen Platzes ist definitiv sein direkter Zugang zum Stettiner Haff mit einem winzigen von Schilf umgebenen Sandstrand. Sonst ist der Platz sehr familiär ausgerichtet, mit einem durchschnittlichen, aber sehr sauberen Sani-Haus ausgestattet und wird von äußerst freundlichen Campern bewohnt. Wer nur mit einem Zelt unterwegs ist, kann es hinter einem Bauwagen verstecken und ungestört beim Einschlafen dem Rauschen der Ostsee und den Flügelflattern eines Vogelschwarms lauschen, der in einer Weide am Strand übernachtet.

Von Bellin gibt es einen ausgeschilderten Schleichweg für Radfahrer zum Ueckermünder Strand, der an Naturwiesen und Feldern vorbeiführt. Ich gönnte mir dort nach den Umwegen des Tages noch eine Stärkung beim Strandimbiss Nordlicht (das Hamburger Schnitzel ist laut Bedienung nicht der Rede Wert, der Zander mit Bratkartoffeln dagegen sehr empfehlenswert), watete noch eine Weile durch die Brandung und rollte schließlich zurück zu meinem Schlafplatz.

Tag 4 Ueckermünde

Jeden Tag damit zu beginnen, sein Zelt zusammenzurollen, kann ganz schön ermüdend sein, gerade wenn man auf einer mehrtägigen Radtour unterwegs ist und ein schönes Fleckchen Erde erwischt hat und daher beschloss ich bereits bei der Planung, zwei Tage in Ueckermünde zu verbringen. Dieser Tag war gewissermaßen mein lazy day, den ich damit begann, einen kurzen Ausflug zum bedenklich nahe der polnischen Grenze gelegenen Dorf Vogelsang zu unternehmen und mich wieder einmal an der Ruhe eines Örtchens zu erfreuen, der von Glück sagen kann, dass er überhaupt auf einer Karte verzeichnet ist. Den Rest des Tages brachte ich damit zu, mich mit Fischbrötchen zu verpflegen, die autoverseuchte Innenstadt näher zu erkunden, dem letzten verbleibenden Touristenschiff Jan van Cuyk der Reederei Peters bei der Aufnahme seiner Passagiere zuzuschauen und es mir am Strand gemütlich zu machen.

Mein persönliches Highlight des Ueckermünder Strands sind seine zwei über hundert Jahre alten Weidenbäume, die UV-aversen Besuchern wie mir angenehmen Schatten spenden, ohne dafür einen Strandkorb mieten zu müssen. Ansonsten bietet Ueckermünde viel Banales und wenig Aufregung. Ein Tag ohne besondere Vorkommnisse, an dessen Ende ich lediglich an einem leidlich starken Sonnenbrand an den Oberschenkeln litt und den ich mangels coronabedingt sinnvoller Restaurantauswahl mit einem Krabbencocktail vom örtlichen Edeka beschloss.

Tag 5 Ueckermünde — Gartz / Mescherin

From Bellin to Gartz (Oder) | Rennrad-Tour | Komoot

Zeit, sich auf den Heimweg zu machen. Der Einstieg in den deutschseitigen Oder-Neiße-Radweg erfolgt an dem vortags bereits besuchten Örtchen Vogelsang und führt dann über glatten Asphalt durch dichte Wälder und versteckte Dörflein vorbei, entlang mooriger Landschaften und man kann bereits auf dem Weg erahnen, was einen direkt an der Oder erwarten wird. Auf dem Weg kamen mir eine ganze Menge Radwanderer entgegen, junge wie alte, schnelle wie langsame und die meisten grüßten freundlich, was immer darauf hinweist, dass die Strecke, die hinter ihnen und damit vor mir liegt, eine halbwegs leicht zu befahrende sein muss.

Auf dem Weg hielt ich kurz für die Länge eines Müsliriegels an einem kleinen Hain an einem traumhaft schönen Feld, das beinahe von absoluter Ruhe eingerahmt war (km 27), die aber auch Pferdebremsen und Libellen für sich entdeckt hatten. Ein paar ziemlich unangenehme Stiche später schwang ich mich wieder auf den Asphalt, um nach etwa 50km in Löcknitz, einem der größeren Städtchen in der Nähe des Oder-Randwanderweges, anzukommen und dort nach einer Mittagsverpflegung zu suchen.

Die typische ostdeutsche Verpflegungsregel gilt auch hier: vernünftige Restaurants sucht man vergeblich und wenn man sich weder für den fettigen örtlichen Ortsimbiss, meistens eine Mischung aus Dönermann und Italiener, noch für ein Kalorien-Puzzle aus dem lokalen Scotty-Netto entscheiden möchte, freut man sich immer, wenn es wenigstens einen Bäcker gibt, der so aussieht, als wenn er einen guten Mohnkuchen zustandebringt. Der mir angebotene war allenfalls durchschnittlich, aber dafür durfte ich ihn bei guter Gesellschaft genießen. Mangels weiterer Sitzgelegenheiten gesellte ich mich zu zwei Damen gehobeneren Alters und wählte als Gesprächseinstieg einen meiner Cool Cats-NFTs, der zu dem Zeitpunkt umgerechnet einige tausend Dollar wert war. Sie hätten von sowas gehört, sagten die Damen und das war unser Einstieg in ein sehr anregendes einstündiges Gespräch über Ökonomie, Gesellschaft, Infrastruktur, Politik und Corona-Impfungen. Anders als befürchtet, bestätigten sich meine plumpen Vorurteile gegenüber des ostdeutschen Landalters keineswegs; beide waren weder Impfgegnerinnen noch offen rechts eingestellt. Der differenzierte Extrakt unserer Konversation war, dass sich diese (und vermutlich auch viele andere) Region Ostdeutschlands auf eine abstrakte Weise abgehängt fühlt. Eine Konsequenz, auf die wir uns verständigen konnten, war die bessere strukturelle Integration, die Schaffung von lokaler Ökonomie, die über Hofläden und Ein-Euro-Shops hinausgehen müsse und die Wiedergewinnung der Attraktivität ländlicher Regionen für den Nachwuchs. Denn es ist kein Vorurteil, dass ein Großteil der hier ausgebildeten Jugend sobald sie die Grenze zur Volljährigkeit überschreitet, in die Großstädte abwandert, in ihrem Falle Schwerin, Hamburg und Bremen.

Nach dieser inspirierenden Mittagspause machte ich mich wieder auf den Weg und folgte ungeachtet des Komoot-Plans nicht der Bundesstraße nach Glasow, sondern folgte dem beschilderten Radweg nach Lebehn, der ab ebendiesem Ort in einen unmöglich zu befahrenden, 3km langen Wirtschaftspfad aus Treibsand mündet. Er gehörte definitiv zu den mentalen Herausforderungen dieser Reise: wer schonmal ein Fahrrad mit Gepäck über diese Distanz geschoben hat, wird mir beipflichten, dass man spätestens ab der der Hälfte eines solchen Trampelpfads damit beginnt, über den Sinn des Lebens nachzudenken. Glücklicherweise gings im Anschluss auf halbwegs glatter Strecke über ein paar Winkel weiter gen Süden. Ein paar Schokoladenkekse, die noch aus Prenzlau übrig waren, retteten die letzten Kilometer. Dort traf ich erstmals auf einen polnisch-deutschen Grenzübergang und bekam einen Vorgeschmack auf das prägende Marschland der Oder.

Mein Ziel war der Campingplatz am Oderstrom am Rand des kleinen Grenzorts Mescherin, auf dem man, obwohl er auf der deutschen Seite liegt, vorrangig polnisch spricht, aber dank seiner Lage an einer der schönsten Radrouten des Landes auch auf Holländer und Briten trifft. Ich schlug mein Zelt unter einer hochgewachsenen Birke auf und stellte nach wenigen Minuten fest, dass auch eine Armee von undefinierbaren Vögeln diesen Baum als Raststätte bevorzugt, sodass ich es rasch einige Meter außer Fallreichweite ihrer Hinterteile bewegen musste. Ganz so aufmerksam war das benachbarte elektrisch unterstützte Radreiseehepaar nicht, aber ich vermied es, sie mit der Situation zu konfrontieren und wünschte ihnen stattdessen innerlich viel Glück und Kraft beim Putzen. Die Sani-Anlagen dieses Camping-Platzes sind definitiv nicht luxuriös und die Duschen erinnerten mich wieder einmal an längst vergangene kompanieweite Gefechtsbesprechungen im Mannschaftsduschraum, aber wenn man einmal alle Scham abgelegt und eine Pferdebremsen- bzw. Zuckersandtortur hinter sich gebracht hat, ist einem warmes Wasser ohnehin wichtiger als der Erhalt männlicher Würde.

Zur Entschädigung und meinem Glück kam ein polnischer Koch auf die Idee, sein “Park-Restaurant” direkt auf diesem Campingplatz zu eröffnen und Gerichte deutscher Prägung anzubieten, es stehen aber auch einige polnische Spezialitäten auf der Karte, darunter Piroggen und Kartoffelpuffer mit Gulasch, aber ich entschied mich für den sicheren Weg und wählte das Zigeunerschnitzel, das hier ganz unschuldig, völlig ungeniert und politisch längst nicht mehr korrekt, seinen ursprünglichen Namen trägt. Wer mit Oma und Opa, Kind und Kegel mal einen netten Ausflug ins Grüne machen möchte, dem sei dieses Plätzchen wärmstens ans Herz gelegt.

Ich beschloss den Tag mit einem Blick in den Himmel: hunderte Wildgänse nutzen die Region um den Campingplatz als Zwischenstopp auf ihrem Weg nach Süden und zogen in ununterbrochenen Schwärmen über unsere Köpfe hinweg. Genauso attraktiv scheint das Fleckchen Erde für Mückenmütter zu sein, die ich als Zentrlalberliner längst für ausgestorben hilt; ihr Nachwuchs bevölkerte in kurzer Zeit meine Beine und wie mir am nächsten Tag klar wurde, war es mir längst nicht gelungen, alle von ihnen in die ewigen Jagdgründe zu schicken. Kurz bevor ich ins Zelt kroch, lernte ich meinen Nachbarn kennen, der ein deutlich ambitionierteres Ziel als ich verfolgte. Er kam aus Zittau und plante 100km-Etappen bis nach Friesland und hatte dafür ein wirklich anspruchsvolles Flaschen- und Taschensetup an seinem Bike befestigt, sodass man kaum noch Rahmen oder Reifen erkennen konnte. Ich wünschte ihm viel Glück und gute Beine und genoss anschließend die Ruhe dieses Ortes. Es gelingt mir wie vermutlich vielen anderen auch selten, in einem Zelt die Nacht durchzuschlafen, sodass ich kurz vor Sonnenaufgang wach wurde und bemerkte, dass man absolut gar nichts hörte. Ein Ziel hatte ich hiermit erreicht: ich versuchte, auf der Tour Orte zu finden, die 100% geräuschlos sind und hier, kurz hinter der deutsch-polnischen Grenze, zwischen Schilfrohr und Gänserastplatz, hatte ich sie plötzlich gefunden.

Tag 6 Mescherin — Parstein

Die Nacht zählte aus besagten Gründen zu den angenehmsten, die ich überhaupt auf einem Campingplatz verbracht habe und so konnte ich morgens nach einer raschen Dusche ziemlich selbstbewusst in den Tag starten.

From Gartz (Oder) to Parstein | Rennrad-Tour | Komoot

Der Weg aus Mescherin führt über einen malerischen, aber schattigen und daher relativ kühlen Wanderweg nahe an der Oder entlang und schließlich trifft er bei Gartz auf den Oder-Neiße-Radweg. Ein großes Schild weist darauf hin, dass er wegen Bauarbeiten geschlossen sei, aber der Wirt des danebenliegenden Cafes versicherte mir glaubwürdig, dass das Schild schon viel zu lange dort stand und der Weg längst wieder befahrbar sei. Am Einstieg des Radwegs (km 6,2) traf ich auf einen reichlich ambitionierten polnischen Radfahrer, der am Morgen in Stettin aufgebrochen war, auf der deutschen Seite bis nach Kostrzyn fahren und auf der polnischen Seite wieder zurückkehren wollte; ich weiß natürlich nicht, ob er das geschafft hat, aber ich habe seine Tour in Komoot spaßeshalber einmal nachgestellt:

Rennrad-Tour | Rennrad-Tour | Komoot

Der Oder-Neiße-Radweg ist gerade für schnelle Fahrer perfekt belegt und führt schnurgerade an der weitestgehend trockengelegten Oderniederung auf dem Deich entlang. Da es nahezu keinen Baumbewuchs beiderseits der Strecke gibt, fährt man allerdings permanent im Wind, was je nach Wettersituation, Fahrrad und Kleidung ziemlich anstrengend sein kann; mich hat der Wind an diesem Tag jedenfalls hart getroffen und machte leichtes Rollen entlang des Weges völlig unmöglich. Entschädigt wurde ich von den grandiosen Ausblicken, den vielen kleinen Haltemöglichkeiten an den Brücken, die zu den malerischen Oderstädtchen führen und vielen freundlichen Radlern, mit denen man sich über Fahrtziele und Ausrüstungen austauschen kann. Nach 20km Kampf mit dem Wind gelangte ich gut durchlüftet in die Industriestadt Schwedt, in der ich mangels Alternative wieder einmal beim lokalen Norma Bananen, Sandwiches und Mineralwasser verpflegte und an einer gut versteckten Parkbank inmitten des “Tabakviertels” der Stadt verschnaufen und mich mental auf die nächsten zwanzig Kilometer entlang des Oderstroms vorbereiten konnte.

Bei Stolzenhagen (km 47) bog ich in Richtung meines Tagesziels Parstein ab und wurde erneut von den auf Pasewalker Höhe bereits bekannten eiszeitlich bedingten Gletscherhügeln getroffen, die 50 Meter über dem Oderspiegel liegen und deren Anstieg ich mit der Ambition eines Alpinspezialisten anging und letztlich nur mit dank Mobilisierung einiger Kraftreserven überwand. Der Campingplatz am Parsteiner See ist großzügig angelegt und schön gelegen und zieht Tagestouristen aus ganz Deutschland an, was nicht zuletzt an seinem namensgebenden Seezugang liegen dürfte. Hier kann man Jesus-gleich über 200m weit durch klares, flaches Wasser in den See hineinwaten, bis er einem schließlich bis an die Hüften reicht.

Ich schlug mein Zelt am Rande der leicht abschüssigen Zeltwiese auf und verpflegte bei “Ron’s Diner”, der Pizzas mit einer Qualität backt, die weit über das erwartbare Niveau eines Lokals auf einem Campingplatz hinausgehen. Sonnenverbrannt, windgebeutelt und kugelrund gegessen blieb mir für den Rest des Tages nicht viel mehr übrig, als von der Liegewiese aus für die Schwimmversuche der Kleinstkinder im 10cm flachen Wasser gedankliche Sternebewertungen abzugeben.

Tag 7 Parstein — Berlin

Man sagt ja, dass Rückwege immer kürzer sind als Hinwege, weil der Gedanke, sein Haupt endlich wieder im vertrauten Heim betten zu können einen Sog der Sehnsucht entfacht, der Beine schneller rotieren lässt. Auch meine letzte Etappe stand unter diesem Zeichen und ich brauchte für die restlichen 76km deutlich weniger Zeit als ich erwartet hatte.

From Parstein to Kreuzberg | Rennrad-Tour | Komoot

Nach einer regnerischen Nacht, die von ständigem Hin- und Herrutschen im Zelt geprägt war, das ich blöderweise auf zu stark abfallendem Gelände aufgebaut hatte, warf ich einen letzten Blick auf die Morgenstimmung über dem Parsteiner See, faltete ein letztes Mal in Ruhe alle Klamotten zusammen und folgte dem Weg in der Richtung, aus der ich vortags gekommen war. Dieses Stück Brandenburg haben kleine Biobauernhöfe und Hofläden für sich entdeckt. Mein Weg führte mich zunächst einige Kilometer auf einem Radweg entlang einer kleinen Landstraße, die von Obstbäumen gesäumt ist und sich nach 10km zu einer Bundesstraße öffnet. An einem Sonntag morgen waren hier erfreulich wenige Fahrzeuge unterwegs und Feuchte der Nacht hing noch in den Bäumen und sorgte für eine angenehme Kühle; perfekte Bedingungen für einen ausdauernden Antritt auf glattem Asphalt. Auf dem Weg nach Eberswalde quert man den malerischen Klosterort Chorin, der sich übrigens als guter Startpunkt für Radtouren Richtung Angermünde und Prenzlau bewährt hat, und von Berlin Hbf mit der Regionalbahn in weniger als einer halben Stunde zu erreichen ist. Ab Kloster Chorin führt wieder ein gut ausgebauter, gerader Radweg Richtung Eberswalde, der sich am Eingang der der Stadt nochmals deutlich verbreitert.

Eberswalde ist ein ansehnliches Städtchen, das wie so viele Orte, die ich besuchte, nicht übermäßig viele Optionen für die Rast bietet, jedenfalls nicht an einem Sonntag morgen. Ich entschied mich wie wahrscheinlich jeder Tourist, der Eberswalde kreuzt, für die offensichtliche: den prominent am zentralen Marktplatz gelegenen Bäcker Gustav. Ein bisschen zu offensichtlich, denn es gab leider keinen Platz mehr, den man mir anbieten konnte und somit blieb mir auch auf der letzten Etappe die Chance auf ein sinnvolles Frühstück in würdevoller Haltung verwehrt. Ich entschied mich für eine Zimtschnecke und eine Sesamseele, die zu den besten Backwerken gehörten, die ich als Convenience Backshop-geplagter Neuköllner seit langem genossen habe (zur Verteidigung: Back.art in der Dieffenbachstraße macht hervorragende Walnussbrötchen und Pasteis de Nata).

Der Weg südlich von Eberswalde führt durch ehemaliges Gletschergebiet und ist mit Sicherheit ein Geheimtip für Wanderer; für Radfahrer gibt es einige kleinere Unebenheiten zu erklimmen, und ich fragte mich, ob ich mit einem saftigen Rührei statt einer trockenen Seele das Umschalten auf den kleinen vorderen Kranz hätte vermeiden können. In Biesenthal tankte ich bei einer erstaunlich gut besuchten Tankstelle eine Club Mate und fuhr ohne weitere Unterbrechung weiter nach Bernau. Der Vorort von Berlin mit seiner alten Stadtmauer und der historischen Kirche mag ein Traumort für stadtnah suchende Eigenheimbesitzer sein, ich fand ihn aber noch nie so richtig überzeugend. Ich durchquerte die Stadt und pausierte an einer lieblosen Industriebrache, wo ich mir den letzten Rest der Eberswalder Zimtschnecke genehmigte.

Man weiß, dass man wieder im Berliner Einzugsgebiet angekommen ist, sobald man die A10 am Dreieck Schwanebeck quert. Hier verlaufen auch relativ gut befahrbare, aber stellenweise verwurzelte Radwege neben der Bundesstraße und ab dem Örtchen mit dem musikalischen Namen Lindenberg steigt die Tankstellendichte um 300%.

Kaum überquert man die Stadtgrenze, wird man selbst an einem Sonntag sofort vom Verkehrswahnsinn der Großstadt erschlagen: Autos die sich an Ampeln stauen, Radfahrer, die einem in der falschen Richtung entgegenkommen, Baustellen und Fußgängerfurten, die die Radwegsituation spontan unterbrechen und Straßenschäden, die einen zwingen, zum Bordstein einen Meter Abstand zu halten sind die typischen Highlights, die der Bezirk Pankow in seinem Norden zu bieten hat. Schon die Parkstraße in Weißensee macht da mit ihrem glatten Belag eine wohltuende Ausnahme, schlagartig besser wird die Situation, sobald man in grüner politisierten Bezirken die Popup-Radwege und baulich getrennten Fahrradspuren in Anspruch nehmen kann. Das tun allerdings gerade Sonntagmittags auch viele andere Radler und so verringerte sich die Durchschnittsgeschwindigkeit bei der Passage nach Kreuzberg gefühlt um die Hälfte.

Aftermath

Nach über 450 getrackten und sicherlich über 50 nicht getrackten Kilometern gönnte ich mir zur Feier der unfall- und plattenfreien Tour ein zünftiges Chicken Madras bei meinem Lieblingsinder am Maybachufer, schüttelte meine Zeltplanen und den Schlafsack aus und genoss es, wieder auf einem bequemen Sofa sitzen zu können. Home Sweet Home könnte man sagen, bis der erste Notfalleinsatz am Kotti mich wieder aus der heimeligen Idylle riss.

Was kann man von dieser nicht allzu anspruchsvollen, aber sicherlich auch nicht trivialen, kleinen Privattour nun mitnehmen?! Zunächst: wenn Ihr einen einen Urlaub an der See machen möchtet, braucht Ihr dafür weder Pkw noch Bahncard, sondern vor allem ein solides Fahrrad, ein bisschen Ausdauer, einen stabilen Gepäckträger und ein bisschen Camping-Equipment. Die meisten Campingplätze haben Waschmaschinen und Trockner am Start, sodass man auch ein bisschen länger an einem Ort verweilen kann, wenn man nicht wie ich den Weg als Ziel sieht. Den Weg zum Ziel zu machen ist allerdings eine ganz wunderbare Möglichkeit, dem Alltag zu entfliehen und ein bisschen was zu erleben; auch wenn ich definitiv keine spektakulären Erinnerungen an diese Tour mit nach Hause genommen habe, überwiegen die vielen Eindrücke, die man unterwegs sammelt, die Mühe, die man manchmal aufwenden muss, um über das hügelige Hinterland zu strampeln.

Ich kann jedem nur empfehlen, es einmal auzuprobieren!

tl;dr

Der Bund hat unter Hochdruck ein Konsortium aus IBM und ubirch damit beauftragt, eine Lösung für digitale Impfnachweise zu entwickeln. Mit dieser Entscheidung setzt man auf eine Lösung, die Impfzertifikate auf mehreren Blockchains verankert, personenbezogene und korrelierbare Daten beim Überprüfen offenlegt und zur Identitätsprüfung weitere analoge Merkmale benötigt.

Wir diskutieren im Folgenden, warum man nicht besser dem international laufenden Standardisierungsverfahren folgt und mit auf Self Sovereign Identities (SSI) basierten Verifiable Credentials (VC) einen Ansatz wählt, der sowohl aus Effizienz-, Datenschutz- und Interoperabilitätsgründen für den internationalen Einsatz deutlich besser geeignet wäre.

––––

Seit dem 9. März 2021 ist klar: Die 2.7 Mio. schwere Ausschreibung des Bundes über die Entwicklung eines datenschutzkonformen, digital auswertbaren und fälschungssicheren Impfnachweises geht an ein Konsortium aus dem Kölner Startup Ubirch und dem Software-Konzern IBM. Innerhalb von 12 Wochen sollen sie (auf Grundlage ihrer bisherigen Entwicklungen) einen Impfnachweis entwickeln, der es Personen ermöglicht, ihren Immunitätsstatus z.B. in Flugzeugen oder an Theaterkassen nachzuweisen.

Im folgenden analysieren, bewerten und kritisieren wir diesen Ansatz. Wir beschäftigen uns seit Anfang 2021 mit digitalen Impfzertifikaten gemäß internationaler interoperabler Standards im dezentralen Umfeld, verfolgen aufmerksam alle Aktivitäten der internationalen Initiativen und entwickeln angesichts der Vielfalt der weltweit zum Einsatz kommenden Impfzertifikate derzeit quelloffen einen “universal verifier”, der in der Lage sein soll, alle Varianten solcher Zertifikate zu verifizieren. Inspiriert wurde dieser Artikel von folgendem Tweet:

JavaScript is not available.

Soso, der Digitale Impfpass „wird kryptografisch signiert und in insgesamt fünf Blockchains hinterlegt"Kann mir bitte jemand erklären, warum man dafür *überhaupt* eine Blockchain braucht?Und wofür vier weitere?

Wir möchten vorwegschicken, dass wir uns zwar mit ubirch’s Protokoll auf Quellcode-Ebene auseinandergesetzt haben, aber mangels direkter Erfahrung mit dem Code einige technische Details im folgenden möglicherweise nicht zu 100% korrekt darstellen. Wir behaupten, dass diese Fehler für die generelle Bewertung des Ansatzes aber zu vernachlässigen sind und beheben sie nach konstruktiven Hinweise gerne nachträglich.

1. Analyse

Wie sich den heute dazu erschienenen Artikeln und Tweets entnehmen lässt, beruht die Sicherheit von ubirchs Lösung auf einer Verankerung der Hashes von Impfzertifikaten auf mehreren Blockchains. Persönliche Informationen sind von diesen öffentlich sichtbaren Hash-Ankern nicht ableitbar. Im Detail ist die Verankerung ein wenig komplizierter, denn würde man tatsächlich jeden einzelnen Hash eines Zertifikats auf eine lineare Blockchain schreiben, stieße man unweigerlich an die Leistungsgrenzen von dezentralen Ledgern.

Daher nutzt ubirch ein Rollup-Prinzip, das auch in Level 2-Netzwerken oder in zugangsfreien dezentralen Dateisystemen wie IPFS genutzt wird. Nodes sammeln über einen längeren Zeitraum Zertifikatshashes, ordnen sie gemäß ihrer empfangenen Reihenfolge zu einer Baumstruktur und bilden daraus einen durch Hashlinks verbundenen Merkle-Tree, dessen Root-Knoten auf der Chain verankert wird. Man kann nun lediglich durch Kenntnis eines Zertifikats, seiner Eltern-Hashes im Merkle-Tree und der Ankertransaktion des Root-Hashes beweisen, dass das Zertifikat zu einem bestimmten Zeitpunkt verfügbar war und seither nicht verändert wurde.

Diese Komplexität hat ubirch ursprünglich nicht für Impfnachweise entwickelt, sondern um massenweise IoT-Events auf Blockchains zu verankern. Daher ist ihre Implementierung primär auf Skalierbarkeit ausgelegt und wird quelloffen in Scala zur Verfügung gestellt. Ubirch stellt Clients in Go, C++ , Java und Python ebenfalls quelloffen zur Verfügung.

Interessant ist die Auswahl von Blockchains, auf die ubirch Ankertransaktionen schreibt:

• Ethereum (Netzwerk unbekannt)
• Ethereum Classic: ein seit 2016 existierender Ethereum-Fork, der mittlerweile nahezu keine praktische Relevanz mehr hat und nicht update-fähig ist
• IOTA Mainnet: ein durch die IOTA Foundation entwickeltes DAG-Protokoll (“Tangle”), das kostenlose geldwerte Transaktionen zulässt, indem es den PoW zu den Clients verschiebt, die dafür zwei vorhergehende Transaktionen (“Tips”) wählen müssen. Bis heute ist IOTA’s Konsens mangels intrinsischer Inzentivierung auf einen zentral betriebenen Coordinator angewiesen, der bereits seit 2017 (!) durch einen kurz bevorstehenden (!!) “Coordicide” obsolet gemacht werden soll. Das aktuelle Vorhaben “GoShimmer” ist auf dem besten Wege dahin, aber es ist nicht klar, ob sich ein uninzentivierter dezentraler Konsens überhaupt in der höchst aversiven Welt der Kryptoprotokolle stabilisieren lässt.
• GovDigital: ein von der gleichnamigen “Genossenschaft zur Integration innovativer IT-Lösungen der digitalen Daseinsvorsorge im öffentlichen Sektor” betriebenes zugangsbeschränktes aber lesefreies Ethereum PoA-Netzwerk (Geth), mit Validatoren aus dem staatlichen / institutionellen Umfeld und fragwürdiger Dezentralität.
• Bloxberg: ein von internationalen Forschungsinstitutionen (z.B. KIT, FIT, TH Köln u.v.a.) aufgesetztes und betriebenes, zugangsbeschränktes Ethereum PoA-Netzwerk mit einem simplen Faucet-System.

Use Cases

Eine einfache Erläuterung des Funktionsprinzips findet Ihr auch hier im Original.

Die persönlichen und medizinischen Informationen, die zur Erzeugung und Verifikation des Zertifikats notwendig sind, werden während der Ausstellung des Zertifikats kodiert, aber unverschlüsselt in einen QR-Code verpackt und dieser dem Patienten mit der Bitte um sichere Verwahrung mitgegeben, z.B. auf Papier, per Email oder einer dafür geeigneten, proprietären Software-Wallet (die vermutlich IBM liefern soll).

Der Hash wird mittels oben genanntem Verfahren mit vielen anderen Hashes zu einem Merkle-Root kondensiert und dieser auf Blockchains verankert. Ein Prüfer kann einen QR-Code scannen, die Klartext-Informationen entnehmen, daraus erneut einen Hash erzeugen und einen ubirch “Filter-Node” beauftragen, ihn mit Hilfe anderer Hashes des entsprechenden Merkle-Trees aufzulösen. Heraus kommt eine Blockchain-Transaktion, die gewissermaßen den Hash der Impf-Informationen des Patienten enthält. So will ubirch sicherstellen, dass die präsentierte Information exakt der entspricht, die zu einem bestimmten Zeitpunkt von einer bestimmten Person (dem “Arzt”) über den Präsentierer getroffen wurde.

Demo

Man kann die Informationen leicht anhand der öffentlichen zugänglichen Demonstratoren extrahieren und auf Blockchains nachverfolgen: Hier ist ein QR-Code, der auf govdigital veröffentlicht wurde:

Wer ihn scannt, erhält folgendes Resultat vom QR-Typ “URL”:

https://ubirch.de/v#f=Mustermann;g=Felix;b=19680812;p=T01000322;i=3CF75K8D0L;d=202008261430;t=PCR;r=n;s=2feffc151cb726bb9ed7

Wer die URL besucht, sieht folgendes:

Ubirch selbst bietet eine Visualisierung der hinterlegten Anker an:

und verlinkt auf die einzelnen Chain-Explorer, in denen man die Ankertransaktion sehen kann:

2. Bewertung

Man muss sich zunächst vor Augen führen, wozu ein Impfnachweis in der Praxis dienen soll; zwei Anwendungsfälle stechen dabei heraus. Im einfachsten Fall möchte man an der “Tür” eines Theaters, einer Bar oder eines Einkaufszentrums sicherstellen, dass die Eintretenden eine vergleichsweise geringe Infektionsgefahr für andere darstellen.

Man kann diesen Case zweifach ausgestalten: Man kann z.B. ausschließlich geimpften Personen den Zutritt gewähren (was effektiv zur Debatte einer Impfpflicht führt, in die wir hier nicht einsteigen möchten), um sicherzustellen, dass selbst wenn eine davon infektiös ist, sich alle anderen nicht anstecken können und von der Veranstaltung selbst keinerlei Gefahr ausgeht, zum Superspreading-Event zu werden. Andererseits kann man Geimpfte und (potenziell) nicht Geimpfte räumlich so stark mischen, dass eine maximale räumliche Distanz zu potenziell ansteckenden Personen gewahrt wird.

Der typische Anwendungsfall ist allerdings der internationale Reiseverkehr: Seit Jahrzehnten erlauben z.B. manche Länder die Einreise nur unter Vorlage einer gültigen Gelbfieberimpfung. Fluggesellschaften können daher durchaus darauf bestehen, dass Fluggäste einen aktuellen Testnachweis oder eben einen Impfnachweis erbringen, bevor sie den Passagier transportieren.

Die Fälschungssicherheit eines Impfpasses mag manchem zunächst als überzogene Anforderung erscheinen, tatsächlich sind Fälle bekannt, in denen sich Reisende illegal Testausweise erschlichen haben und deren Aussteller dafür auch hart bestraft wurden. Der Schwarzmarktpreis eines gefälschten Testergebnisses lag laut diesen Quellen zwischen 150 und 300€.

Hab mir schonmal einen Impfnachweis besorgt, inspiriert vom Beispielcode auf der Website pic.twitter.com/hZgx64NfyL

Die ubirch-Lösung entspricht in ihrer Handhabung etwa dem Verfahren, das in China oder Israel (“Green Pass”) zum Einsatz kommt: Der Nachweisführende präsentiert eine Ankerinformation und persönliche Merkmale, der Verifizierer schlägt das entsprechende Zertifikat nach, prüft dessen Echtheit und gleicht ein analoges Merkmal (z.B. den Namen einer Person) vor Ort ab. Unter Gesichtspunkten des Datenschutzes ist ubirch vermutlich vielen anderen Lösungen weit voraus, da die Impfnachweise selbst in keinem zentralen Register stehen, sondern vom Nachweisführer selbst beigebracht werden.

3. Kritik

Wer ist eigentlich berechtigt, solche Impfzertifikate auszustellen? Einfache (naive) Antworten: das BMG, Hausärzte, Bundeswehrsoldaten im Impfzentrum oder Vertrauensstellen der Krankenkassen. Transportiert man diese Antworten ins Digitale, wird es aber plötzlich sehr kompliziert: Wer verhindert, dass ich als Programmierer kein Zertifikat über mich selbst ausstelle, und es mit Hilfe der für Verifizierer offen zugänglichen Nodes auf eine Blockchain schreibe?

Es gibt für diese Frage einige sehr gute Antworten, die Ihr weiter unten findet. Im Rahmen der ubirch-Lösung ist sie aber primitiv: Irgendjemand muss den schreibenden Zugang für die Zertifikatshashes beschränken. Anders formuliert und sehr stark vereinfacht: Eine Hausarztpraxis muss sich bei ubirch “anmelden”, damit sie Zertifikate für ihre Patienten ausstellen und verankern kann. Die Kooperation mit IBM soll in Deutschland dafür sorgen, dass dieser Prozess reibungslos in den Praxis- / Impfzentrumsalltag integriert wird. Hier ein Zitat von der ubirch-Website:

Der Digitale Impfnachweis wird vor Ort im Impfzentrum oder beim Hausarzt erstellt. Die erforderlichen personenbezogenen und Impfdaten können direkt aus dem vor Ort genutzten System übernommen werden. Dafür gibt es bereits Integrationen wie beispielsweise in Excel, weitere sind möglich. Alternativ werden die Daten über ein schlankes WebInterface bzw. eine App erfasst. Durch eine weitestgehende Automatisierung bleibt der Aufwand minimal und lässt sich leicht in den Impfprozess integrieren.

Um die Systeme von Hausärzten dazu zu autorisieren, solche Zertifikate mit Hilfe von ubirch-Nodes auf Blokchains zu verankern, bedarf es eines großen organisatorischen Integrationsaufwands: Arztpraxen müssen sich gegen IBM / ubirch authentifizieren (wer die Debatte um den KBV-seitigen Heilberufsausweis verfolgt weiß, wie viel Sprengstoff dieses Thema birgt) und unterliegen nun allen Gefahren, die eine zentrale Autorisierung mit sich bringt: verlorene Schlüssel, betrügerische Absichten, Mehrfachverwendung von Schlüsselmaterial, Kompromittierung der Schlüsselkarten, technische Komplikationen usw.

Nachweisführung und Identifikation

Wer am Fluggate seinen ubirch-Impfnachweis vorlegt, präsentiert vorrangig ein (digitales) Stück Papier, dessen Inhalt der Verifizierer auf einer Blockchain nachschlagen und damit ziemlich sicher sein kann, dass die Informationen auf dem Papier korrekt sind und zu welchem Zeitpunkt sie ausgestellt wurden. Diese Information alleine würde keinesfalls genügen, um eine Impfung der Person zu bescheinigen, weil sie sehr einfach kopierbar ist. Daher muss der Nachweisende zusätzlich persönlich identifizierbare Informationen vorlegen, die Bestandteil des Zertifikatshashes sind. Im aktuellen ubirch-Fall sind dies (es werden die Anwendungsfälle “Corona-Test” und “Corona-Impfung” behandelt)

• der volle Name
• das vollständige Geburtsdatum
• Eine persönliche Identifikationsnummer (z.B. Reisepass oder Patienten-ID)
• Eine Identifikationsnummer des Tests bzw. Impfnachweisdokuments
• Ein Testdatum bzw. die Impfdaten
• Die Testmethode bzw. der verwendete Impfstoff
• das Testergebnis (positiv / negativ)

Sobald ein Verifizierer sich vergewissert hat, dass er dem Zertifikat selbst trauen kann, vergleicht er nun diese Informationen mit weiteren Merkmalen des Nachweisführers, z.B. dessen Personalausweis.

Ich hoffe, jemand hat die Glocken gerade klingeln gehört: Es stecken zwar keinerlei private Informationen im Ankerzertifikat, aber jeder Verifizierer erhält an dieser Stelle Zugriff auf eine Menge persönliche und medizinische Informationen, die für den eigentlichen Nachweis einer Immunisierung völlig überflüssig sind. Da dieser Abgleich manuell stattfindet, ist er fehleranfällig und wenn man ihn digitalisiert führt er zu einer maximalen Korrelierbarkeit personenbezogener Daten.

Das ist im internationalen Flugverkehr sicherlich noch hinnehmbar, aber für lokale Usecases ein maximales Datenschutzdesaster: Warum sollte Dieter Hallervordens Schlossparktheater (das Ihr bitte sofort besucht, sobald Ihr Eure zweite Impfung im Arm habt!) oder die Monkey-Bar Eure Versichertennummer oder Euren Geburtstag erfahren, wenn Ihr einfach nur nachweisen müsst, dass Ihr geimpft seid?

Sicherheit der Nachweisführung

Richtig Spaß macht ein Impfnachweis, der monatelang auf einem Zettel zusammen mit dem Personalausweis durch jede Bar getragen wird, nicht. Daher arbeitet die IOTA Foundation zusammen mit einem der namhaftesten Hersteller von fälschungssicheren Smartcards (Zebra) an einem Impfausweis auf einer Plastikkarte, die sowohl die gedruckten Informationen des Zertifikats und den entsprechenden QR-Code, eine über NFC zugängliche digitale Version des Zertifikats und als zusätzliches Sicherheitsmerkmal (“Evidence”) das Passbild des Trägers enthält.

Davon abgesehen, dass der Druck einer solchen Karte nicht billig und auf planetarem Scale auch kaum durchführbar ist, stellt sich die Frage, ob der impfende Arzt auch ein Foto des Patienten schießen soll oder ob man es durch Korrelation mit den Versichertendaten (Stichwort: ePA / eGK) beziehen kann und wer diese Schnittstelle in sicherer Form bereitstellen könnte oder, viel einfacher: Wer die dafür notwendigen Zebra-Drucker betreibt und finanziert.

Wer braucht eine Blockchain, wenn er 5 benutzen kann?

Wirklich absurd wird es, wenn man die Onchain-Speicherung der Impfnachweise betrachtet. Der einzige denkbare Grund, warum man den Nachweis (bis zu) 5x auf irgendwelchen ominösen PoA-Chains verankert ist, dass eine dieser Blockchains oder der Zugang für Verifier zu ihnen “ausfällt” oder der beschränkte Zugang zu ihnen kompromittiert wird und es einem Angreifer gelingt, Transaktionen zu schreiben, die er nicht schreiben können sollte.

Das ist genau der Grund, warum jeder, der das Thema Blockchain wirklich ernst nimmt, verstehen sollte, dass permissioned Blockchains außerhalb eines industriellen bzw. notariellen Einsatzes (z.B. in ubirch’s ursprünglichem Usecase der Maschinentransaktionen oder im POAnetwork) keinerlei Vorteile gegenüber replizierten Datenbanken haben.

Blockchains ermöglichen es dank ihres verteilten Konsensmodells, dass einander völlig unbekannte Teilnehmer, die sich nicht nur nicht vertrauen, sondern sogar gegenteilige Interessen vertreten, miteinander auf einer vertrauensvollen (bzw. vertrauenslosen, je nach Betrachtung) Grundlagentechnologie miteinander Transaktionen austauschen können — ein Konzept, das als “Coopetition” bekannt ist und das Ethereum Mainnet zu einer außerordentlich gut funktionierenden, bis heute nicht kompromittierten Plattform des maschinellen Vertrauen gemacht hat, die tagtäglich Milliardenwerte absichert und verschiebt.

Die Stabilität dieser Netzwerke wird intrinsisch inzentiviert: Dadurch sind sie ab einer gewissen Größe (z.B. durch die Verteilung von PoW-Minern oder der Verteilung von PoS-Stakes im Eth2-Netzwerk) absolut unkomprimittierbar und unabschaltbar; fällt ein Node aus, kann man sich jederzeit mit einem anderen verbinden.

Eines der größten Missverständnisse von klassischen Unternehmen, die Blockchain-Technologie für sich entdecken ist, dass man ein “dediziertes” Blockchain-Netzwerk aufsetzen und mit Passwörtern nur bestimmten Teilnehmern zur Verfügung stellen kann. Man verschiebt damit nämlich den grundsätzlichen Sicherheitsgedanken, dass Teilnehmer ihre Berechtigungen durch transparente Smart Contracts gewährt bekommen, an die Vordertür der Validator-Nodes und verliert alle Mechanismen, die onchain zur Absicherung und Vergabe dieser Berechtigungen vorhanden sind, wie Multisignatur-Wallets, DAOs oder tokenbasierte Rechte-Vergabe.

Doch die viel relevantere Frage ist: Muss man überhaupt Impfzertifikate auf eine Blockchain schreiben, damit sie sicher sind?

Nein.

4. Die bessere Alternative: Verifiable Covid Credentials

Stell Dir vor, die ganze Welt einigt sich gerade auf eine Lösung, aber ein deutsches Startup hat eine “bessere” Idee.

Die Herausforderung, einen sicheren digitalen und maximal interoperablen Impfnachweis herzustellen, der auch auf globaler Ebene für alle möglichen denkbaren Einsatzszenarien funktioniert, und ihn binnen weniger Monate zu realisieren ist so groß, dass viele kluge Köpfe sich seit längerer Zeit damit beschäftigen. Sie versuchen, zu einem globalen Konsens über Formate und Interaktionen auf Grundlage dafür geeigneter Technologie-Stacks und -Standards zu gelangen. Für Implementierer innerhalb der Europäischen Union setzt ein Papier der Europäischen Kommission vom 27. Januar 2021 die Richtlinien, nach denen ein Impfnachweis idealerweise gestaltet werden sollte:

Initiativen

Ehrlich: Wie viele Unternehmen, glaubt Ihr, arbeiten weltweit an dem Problem der “nachweisbaren, unfälschbaren, interoperablen, datensparsamen Impfzertifikate”? Wir haben nicht gezählt, aber hier sind ein paar der größten Initiativen, die viele Partnerunternehmen hinter sich vereinen oder auf Grundlage staatlicher Vorgaben längst an global einsetzbaren Lösungen arbeiten:

• Good Health Pass Collaborative (gegründet im Februar 2021)
  eine technologisch agnostische unabhängige “Dachorganisation”, die primär die Kommunikation zwischen Herstellern koordinieren möchte und der auch ubirch angehört.
• Linux Foundation Public Health Covid Credentials Initiative (Q2/2020)
  arbeitet primär im nordamerikanischen / britischen politischen Umfeld und vereint Initiativen zur schematischen und technischen Ausgestaltung eines SSI/DID/VC-Prozesses

• Vaccination Credential Initiative (Dez 2020)
  Microsoft, Salesforce, Oracle u.a., arbeiten an einem Credential-Standard auf Grundlage der sog. FHIR4/HL7 kompatiblen SMART Health Cards (Microsoft)
• CanImmunize
  Kanadische Initiative zur Definition eines auf medizinischen Formaten basierenden Impfdokuments
• IATA Travel Pass
  eine von Fluggesellschaften getriebene Initiative, einen digitalen “Travel Pass” zu entwickeln, um den internationalen Flugverkehr wieder öffnen zu können

Eine weit darüber hinaus gehende, außerordentlich erschöpfende Liste vieler Unternehmen, die bereits Lösungen hierfür vorgestellt haben, die in einigen kleineren oder größeren Ländern (Indien!) bereits im Einsatz oder der Erprobung sind, hat der kanadische Startup-Gründer und Canimmunize-Supporter David Janes in einem detaillierten Google Document zusammengetragen.

Self Sovereign Identity & Verifiable Credentials

Seit 2014 tragen unterschiedlichste Unternehmen unter dem Dach der Decentralized Identity Foundation (DIF) Spezifikationen, Implementierungen und Standards zusammen, die nicht weniger als der Revolution der Frage nachgehen: Was ist eigentlich eine digitale Identität und wie weist man sich damit gegenüber digitalen Systemen aus? Im Kern funktioniert es wie folgt:

• Eine Identität ist eine Sammlung von Schlüsselpaaren, die vollständig unter der Kontrolle einer Entität (Mensch oder Maschine) sind.
• Technisch wird diese Identität durch einen global eindeutigen Dezentralen Identifizierer (DID) repräsentiert, z.B. did:ethr:0x90f8bf6a479f320ead074411a4b0e7944ea8c9c1
• Mit Hilfe von sogenannten Resolvern lassen sich DIDs zu DID Dokumenten auflösen, die das gerade aktuelle, öffentliche Schlüsselmaterial, das eine DID benutzt zugänglich macht. Es gibt vielfältige zentrale und dezentrale Verfahren, darunter auch Blockchain-basierte, wie ein Resolver die vom Controller hinterlegten Schlüssel seiner DID zu einem DID Dokument auflösen kann. Eine naive ist die Verankerung von Changesets als Events auf der Ethereum-Blockchain, komplexere wie das chain-agnostische Sidetree nutzen dafür Merkle Tree-Verfahren, um mit Hilfe von DLTs viele Changesets in einer nachweisbaren Ordnung zu speichern. Firmen wie Jolocom arbeiten z.B. an einer vollständig Peer-basierten Identität, die ihre selbstsignierten Changesets als lokal verifizierbares Eventlog (KERI) auf Anfrage mit Resolvern teilt.
• Ein DID-Dokument enthält keinerlei personenbezogene oder sonstige Profilinformationen wie E-Mail-Adressen oder URLs. Es enthält stattdessen lediglich die aktuelle Liste an Public Keys, deren Verwendungszwecke und Referenzen auf Registrierungs-Dienste, auf denen man mit der DID zusammenhängende Informationen abrufen kann. Dennoch gibt es Anbieter, die eine DID mit einem “gewohnten” sozialen Profil anreichern, wenn man das möchte. 3Box war dafür ein großartiges Beispiel, befindet sich aber derzeit in einer großen strategischen Transformation.
• Die privaten Schlüssel hinter der DID müssen vom Inhaber sicher aufbewahrt werden. Hierfür gibt es zahllose Wallets (z.B. Jolocom, lissi, trinsic, connect.me), die mehr oder weniger nutzerfreundlich unter Zuhilfenahme von Secure Elements, Passphrases, Mnemonics oder biometrischen Verfahren ein grundlegendes hohes Sicherheitsniveau herstellen
• Der Controller einer DID kann seine privaten Schlüssel nutzen, um Daten für verschiedene Anwendungsfälle zu signieren
• Der wichtigste Anwendungsfall ist die Ausstellung von “Verifiable Credentials” (VC). Das sind Statements (“Claims”), die eine Identität über eine andere trifft und die kryptografisch von einem “Verifier” überprüfbar sind. Das klassische Beispiel für VCs ist ein “Universitätsabschluss”, den eine Universität über einen Alumni ausstellt und ihm diesen an eine Credential-Wallet überträgt.
• Verifiable Credentials sind in sich geschlossene, maschinenles- und kryptografisch überprüfbare Dateien, die theoretisch in jedem beliebigen System aufbewahrt werden können. Der “Träger” eines Credentials wird als “Holder” bezeichnet und wird zum “Prover”, sobald er von einem “Verifier” darum gebeten wird, ein Credential, das bestimmten Kriterien genügt (“hat Universitätsabschluss”) zu präsentieren

• Die Claims innerhalb der VCs (“subjects”) werden üblicherweise in klar schematisierten JSON-LD Datenstrukturen abgelegt, sodass ein Verifizierer ohne Kenntnis der ursprünglichen Claim-Absicht eine Vorstellung von der Semantik der Felder innerhalb des Claims erhalten kann.
• Es existieren bereits in der Praxis sog. zero knowledge-Verfahren, die es einem Holder erlauben, einem Verifier nur bestimmte, oder sogar funktional abgeleitete Aspekte eines Credentials zu präsentieren, ohne dass der Herausgeber diese Kombination oder Variation bei der Erstellung des Credentials vorausgesehen oder individuell signiert hätte.

Immunization Credentials

Um ein global akzeptiertes “Covid Credential” für Tests oder Impfungen herauszugeben, muss sich die Community darauf einigen, welche Informationen für einen Impfnachweis überhaupt relevant sind. Das oben genannte Papier der europäischen Kommission gibt dafür eine gute Vorlage, aber auch Spezifikationen innerhalb des FHIR/HL7-Konsortiums (getrieben von Microsoft) oder der global anerkannten “Semantic Web” Initiative schema.org sind auf einem guten Weg, einen akzeptablen Standard für medizinische Informationen innerhalb von Credentials zu entwickeln, der mit Medizinsystemen generell kompatibel sind. Selbst wenn es mehrere solcher Standards gibt, ist ein Verifier entweder durch Auflösung der referenzierten JSON-LD Schemata oder durch Auflösung eines referenzierten Credential Schemas die Semantik eines Claims innerhalb eines Credentials zu verstehen.

Der Prozess, nach dem Credentials zwischen Issuer und Holder bzw. zwischen Prover und Verifier ausgetauscht werden, ist grundsätzlich spezifiziert und referenzimplementiert (Jolocom, Hyperledger Aries). Der Standard, nach dem alle Parteien gegenseitig verschlüsselt Informationen miteinander austauschen, ist ebenfalls spezifiziert (DIDComm 2.0, Jolocom), aber noch längst nicht von allen Parteien interoperabel umgesetzt.

Wann ist der Arzt eine Ärztin?

Verifiable Credentials werden durch einen autorisierten Issuer (“Arzt”) herausgegeben, der dafür zunächst nicht notwendigerweise bei einer zentralen Stelle “angemeldet” sein muss. Die Erstellung von Credentials kann gemäß Spezifikation offline geschehen, wird von vielen kommerziellen Anbietern aber gerne kostenpflichtig angeboten. Jemand, der sich für einen Arzt hält, kann daher völlig unbeschränkt Impfzertifikate an beliebige Personen ausstellen, die niemals auf irgendeiner öffentlich sichtbaren Blockchain landen. Wer ein solches Credential präsentiert bekommt und die DIDs von Patient und Arzt resolven kann (dafür benötigt er ggf. lesenden Zugang zu einer öffentlichen Blockchain, auf dem die DIDs von Arzt und Patient verankert sind), kann jederzeit verifizieren, dass der Inhalt des Credentials kryptographisch der Wahrheit entspricht.

Das eigentliche Problem ist aber auch hier die Frage “ist der Arzt wirklich ein Arzt?”. Sie lässt sich im SSI-Szenario auf zwei Arten beantworten:

• Es existiert eine zentrale Registratur, die DIDs (oder Delegate-Keys) von Ärzten aufnimmt, die von übergeordneten Stellen (“WHO”, “BMG”, “KBV”) kontrolliert werden. Diese Registratur kann als Smart Contract oder DAO auf einer Blockchain implementiert sein, um maximales Vertrauen und Transparenz über die Issuer aufzubauen, sie kann aber —eine Analogie zu den “permissioned” Blockchains — auch mit einer hochverfügbaren Datenbank mit starker Zugangssicherheit implementiert werden.
• Es gibt nur einige wenige “Root”-Akteure (WHO, BMG, KBV), deren DIDs in einer (de)zentralen Registratur als solche ausgezeichnet werden. Ihre Anzahl ist so gering (weltweit wenige 1000), dass sie ohne weiteres auf einer öffentlichen Blockchain abgelegt werden können. Diese Akteure signieren zeitlich begrenzte “Arzt”-Credentials, die sie an Ärzte ausstellen und in einer öffentlich zugänglichen Credential Registry hinterlegen. Diese Registry sollte zwar aus Skalierungs- und Stabilitätsgründen dezentral angelegt sein und Schreibzugriffe nur von Root-Akteuren akzeptieren, muss aber keinesfalls auf Blockchains basieren — hierfür eignen sich dezentrale Filesysteme wie IPFS oder Sia ganz hervorragend. Ein Verifier, der einen Impfnachweis validieren möchte, prüft zunächst die Signatur des Arztes, sucht danach die DID des Arztes auf der dezentralen Credential Registry und prüft, ob ein dort hinterlegtes “Arzt-Credential” von einem der global beglaubigten Root-Akteure ausgestellt wurde. Dieses Verfahren erinnert an die “Chains of Trust”, die z.B. Browser nutzen, um SSL-Zertifikate zu überprüfen. Tatsächlich eignen sich auch herkömmliche X.509-Zertifikate zur Ausstellung von Credentials und DIDs, sind aber in Zeiten von kurvenbasierter Kryptographie (insb. Secp256k1 und EdDSA) eher unüblich.

Vorteile von Credential-basierten Lösungen gegenüber Chain-verankerten Zertifikaten

Der immense Vorteil eines Credential-basierten Impfnachweises ist die dezentrale Datenhaltung beim Patienten und die Verschiebung des Trust-Verhältnisses von einem chain-basierten Anker hin zu einer lokal verifizierbaren Signatur. Es gibt absolut keine Notwendigkeit, das Zertifikat selbst auf eine (oder 5!) Blockchain zu schreiben, weil die Credentials kryptografisch gegen Manipulation geschützt sind.

Weiterhin besteht keinerlei Notwendigkeit, Nodes zu betreiben, die Impftransaktionen zu einem nachweisbaren Merkle-Tree Root zusammenführen oder auflösen. Damit entfällt auch die Notwendigkeit von zentraler Infrastruktur, die ubirchs Lösung voraussetzt, um den Hash eines vorgelegten Impfnachweises auf der Chain finden zu können.

Die Informationen des Impfzertifikats können, wenn man etwas mehr Energie in die Implementierung und Herausgeber-Logik investiert, vom Patienten selektiv präsentiert werden. Für den Besuch in einer Bar genügt es, wenn der Prover nur die Signaturen über den Impfnachweis übermittelt (zuzüglich einer Wegwerf-Signatur, um damit gleich auch die Luca-App überflüssig zu machen, aber das ist wieder ein anderes Thema)

JavaScript is not available.

Thread: ich werde immer öfter zur #LucaApp gefragt, die Clustererkennung zB in Restaurants ermöglichen soll, deshalb hier meine aktuelle Position dazu:- mich überzeugt die App bisher überhaupt nicht (Gründe weiter unten) - mich beunruhigt die Euphorie staatl. Stellen zur App /1

Es gibt eine überwältigende Menge an “Smart Wallets”, die hervorragend dafür geeignet sind, sowohl private Schlüssel der DIDs als auch die Credentials zu speichern, zu validieren und zu präsentieren. Hier ist eine Auswahl aus mehr als 150: Jolocom, Lissi, Connect.me, Trinsic und Civic.

SSI/DID-Technologien werden von Europa im Rahmen des EBSI und der ESSIF unterstützt und gefördert. In Deutschland arbeitet die Bundesdruckerei an eIDAS-konformen SSI-Lösungen, die auch beim deutschen Personalausweis zum Einsatz kommen werden. Es gibt vom Bund geförderte Initiativen wie IDUnion, die dedizierte dezentrale Identitäts-Netzwerke aufbauen und vorantreiben. Als Followup des “Schaufensters Sichere Digitale Identitäten” gehen 4 Projektkonsortien ab April in eine Prototyping-Phase über, in der sie im Feld gut verwendbare SSI-Lösungen für verschiedenste Anwendungsszenarien umsetzen.

Abwägung

Wenn also SSI- und Credential-basierte Verfahren so offensichtlich besser für Impfnachweise geeignet sind und international für den Einsatz vorbereitet werden als chain-basierte Zertifikatsanker, warum hat sich der Bund bei seiner Ausschreibung dagegen entschieden?

Man muss es klar sagen: SSI-Technologie ist trotz ihrer Historie und ihres revolutionären Anspruchs, digitale Identität vollständig zu liberalisieren, ebenfalls ein hochexperimenteller Ansatz. Ihr nachhaltiger Erfolg wird sich erst in einigen Jahren in der Breite einstellen, unter anderem auch untermauert durch eine eIDAS-kompatible Identität, die an den Personalausweis gekoppelt ist.

Wenn man die Wahl zwischen zwei hochexperimentellen Technologieansätzen für einen Anwendungsfall hat und eine Menge Budget, um sie umzusetzen, warum entscheidet man sich dann nicht für den, der in vielen Bereichen des öffentlichen und privaten Lebens Einzug halten wird, sondern für eine Insellösung, die zwar ein grundsätzliches Problem löst, danach aber nur in industriellen Nischen Relevanz hat?

Fazit

Vor dem Hintergrund der mit Hochdruck vorangetriebenen selbstsouveränen Identitäten ist es unlogisch, für Impfzertifikate auf eine Lösung zu setzen, die

• sich an keinen semantischen Standard hält,
• jedem Verifier eine unnötige Menge an privaten Informationen offenlegt,
• Daten unnötigerweise auf (obskuren) Blockchains verankert,
• auf proprietäre Lösungen zur Arztidentifikation angewiesen ist,
• sich an keine Regeln internationaler Interoperabilität hält und
• zur Überprüfung der Identität des Nachweisenden weitere analoge Merkmale zwingend voraussetzt

Warum sich der Bund im Rahmen einer 2,7 Mio. Euro starken, intransparenten Ausschreibung für dieses Konsortium entschieden hat, wird bis zur Darlegung der Entscheidungskriterien ein Rätsel bleiben. Sich für eine Lösung zu entscheiden, die im Feld, z.B. am Flughafen FFM und im Freistaat Bayern bereits vertestet wurde, liegt nahe. Das bedeutet aber nicht, dass sie interoperabel oder international anschlussfähig ist.

Uns bleibt nur zu sagen: Was auch immer Ihr für Impfzertifikate bauen wollt, wir werden versuchen, sie alle zu verifizieren! Toi toi toi.

Wer mitmachen möchte, unser Repo (sehr viele weiterführende tiefe Links im Readme!) und das dazugehörige NPM-Package findet Ihr hier:

• elmariachi111/ultimate-non-infectious-verifier
• @univax/core

Wer baut den besten Impfausweis? was originally published in t14g on Medium, where people are continuing the conversation by highlighting and responding to this story.

A decentralized approach for managing events, conferences and attendees

Beginning of October many local community organizers received a notification by wework owned meetup.com stating that they plan to evaluate changes to their business model. Put shortly, their idea was to either charge every attendee a 2 Dollar fee for every RSVP while at the same time lowering the yearly costs for event organizers to 24 Dollars. What effectively sounds like a worthwhile idea to raise attendance rates, it could easily be interpreted as a desperate move by wework to monetize their remaining assets. If you’re interested in the whole story, The Verge has got a fantastic writeup here.

Tim Myers on Twitter

@Meetup How do I cancel my account and delete all of my data. Asking for 19,000 friends?

This incident that I personally refer to as “meetup meltdown” makes one thing very clear: as long as you rely on a third party you will fully depend on their good will. They set the rules, that you have to play along and they can change them any time. Even worse: if they go down because of this, they’ll take you with them.

Bridget Kromhout on Twitter

Hey @Meetup, I just paid you $98.94 for 6 months. Our Thursday meetup this week has 139 RSVPs right now, so you're saying you'll want $278 additional for such an event. I'm obviously not charging admission. Either you're changing this or we're leaving you. https://t.co/W2vspzwoVs

jer on Twitter

If any of these changes are coming to any of my Meetup groups I'm gonna close them down and switch to something else. https://t.co/iaGbNE7pst

In the aftermath of the announcement many people jumped over board immediately. Regardless of the not too evil idea to charge (and even return!) a ridiculously low fee, nobody wanted to be the one to pay the bill for wework’s disastrous attempt to go public in September. Which is a legit decision. But here’s the issue: if you’re not on meetup.com — where are you building your community then? Suddenly alternatives were popping up like flowers in the desert after a rain shower: it felt like thousands of tweets by anxious meetup hosts hit our timelines, asking “Which alternative would you recommend?” And the world is not short of them.

If you think about it for a moment, any attempt to switch from meetup.com to yet another platform will end in an evil circle of doom: once that platform has to handle the whole load of planet earth’s meetup movements, it will sooner or later also come to the conclusion that charging a fee might be a good idea for one or another reason. So it’s time for smarter approaches that allow them to think slightly different.

FreeCodeCamp founder Quincy Larson posted a tweet only hours after the meltdown incident encouraging his worldwide active coder community to start building a distributed alternative for FCC chapters right now. And the community followed.

Quincy Larson on Twitter

freeCodeCamp is building an open source alternative to Meetup. - No fees for organizers - No fees for participants People have been asking us for a free event tool for years. Now Meetup's new pricing scheme is forcing our hand. Let's build it together: https://t.co/1Po1I5l8C2

Within hours a dedicated Discord channel went wild with around one thousand more or less experienced hackers, many of them seemingly skilled in frontend matters. Only a day later their github repo opened up and the discussion was piped into an endless stream of feature requests. Everybody seemed to have a good idea of how the organization of local community events could be improved. Everybody wanted to be aboard when the whole world starts to establish an open source meetup community platform. The first thing to see on the README was a relational diagram depicting the relations between users, organizers, venues and events — and it was no coincidence that it looked similar to the concepts that we knew so far as: meetup.com.

The FreeCodeCamp “chapter” repo takes it one step further, though. They absolutely recognized that a centralized platform will sooner or later end up with similar issues as our federated friends, so they want to distribute the moving parts on as many shoulders as possible. Local communities would run their own nodes and install the containerized chapter software on them.

The only centralized part in the system — as the time of writing — would be a discovery service making it possible for new users to find their local community’s hub nodes. A splendid idea. But you’d still need encouraged locals who are willing to take action and install and maintain a running chapter node (which obviously doesn’t come for free) and tell everybody to create accounts on them.

This kind of distributed linked network is not brand new: Mastodon and Matrix (the backbone of Riot.im) are quite successfully building Twitter and Telegram replacements. Kazaa and Diaspora were showing early that P2P controlled filesystems and social networks, operated by globally distributed peer nodes had the perspective to break the restrictions of centralization.

But do you really want to build software using relational databases and machine based application hosting in the year 2020? SQL dates back to 1974, and in the days of serverless functions, running a server also leaves the bad feeling of working with zombie technology here.

The dawn of decentralized

A ghost is roaming web town and its name is “Web3”. A phrase that follows up the early 00’s notion of a “Web2.0” that became a synonym for applications that embrace web technologies and exchange data with their home servers asynchronously aka “AJAX”. Web3 is all about decentralized applications and protocols: not a single server, company or developer should be responsible for uptime, assets and data but the network as a whole. The Web3 concept already has taken huge steps towards production readiness to change the way how we execute distributed code and synchronize trusted application state among peers.

One of the most accepted and proven decentralized application platforms is the Ethereum Virtual Machine (EVM). Even today many people are probably misunderstanding the blockchain based Ethereum platform as a bare ICO-enabling, token mining, crypto-kiddie, ecologically questionable crypto-scam. Or simply put, a Bitcoin on steroids. Only that it isn’t.

At Etherum’s very foundation every node runs a bytecode interpreter. Miners are executing code written into the Ethereum blockchain simultaneously and deterministic while mining new blocks. Clients can add EVM executable bytecode to their transactions to have the miners run it and since it’s written and hashed in blockchain transaction code, it’s unchangeable, untinkerable and unbreakable. Therefore people refer to this kind of code as smart contract: nonnegotiable sets of rules that are carved in stone, forever.

Just a fun fact here: the term “smart contract” has been coined in the 90s by mathematician Nick Szabo, long ago before blockchains ever had been thought of. Some people assume that Szabo is actually the man behind the ominous “Satoshi Nakamato” who once kicked it all off with his Bitcoin whitepaper (but he always denied that since). Yet another fun fact: the trillionth part of 1 Ether is also referred to as 1 “Szabo” as an homage to his theoretical contribution.

When you are going down a step from the philosopher’s cloud, coding smart contracts feels not too unrelated to coding in centralized programming concepts. While you’re free to roll your own, the Ethereum foundation introduced their Turing complete smart contract language “Solidity” as early as of 2014. Solidity smart contracts carry intrinsic state, have public and private methods that can mutate the contract’s state, can emit events, may contain value (expressed as Ether balance), support pure functions and can inherit code from other contracts and interfaces. For most developers Solidity smart contracts should therefore feel familiar: they’re more or less classes. Or put precisely: classes for persistent objects that represent their behavior and state schema. Many people can potentially deploy the same smart contract on Ethereum, effectively spawning instances of it.

Interacting with a smart contract in a state-changing way doesn’t come for free. Miners who execute the contracts’ code must run CPU cycles to execute the compiled bytecode. Ethereum therefore introduces the concept of “gas” to represent fees that are spent on every code execution step. Depending on the operation’s complexity an Ethereum client estimates an amount of gas that’s needed for the computation. At the time of execution a miner translates the gas value to “real” Ethers and expects it to have been sent along with the contract invoking transaction — if the sent funds aren’t sufficient, miners will reject the transaction. Every user who wants to interact with any smart contract in writing direction must therefore pass an appropriate amount of gas with the call.

Smart contracts are unstoppable and enable the authoring of so called decentralized apps (or short Đapps). From a very simplified practical point of view they’re frontend heavy applications that use the Ethereum ledger as event source and database.

Getting started with a decentralized event platform

In early August 2019, during an internal hacking event called “BREAKOUT”, a team of 5 Turbine Kreuzberg engineers, POs and agile coaches formed team “Ethickets” to learn about Ethereum’s concepts and build a simple meetup clone.

Our first idea was to only store a list of RSVPed attendees on the ledger and maintain all the event details in a Symfony based backend application that interacts with Ethereum on a local Geth node through an Elixir based gateway application. A React Native client should then enable users to discover and claim “tickets” for an event. At the event’s door somebody could manually check whether an attendee could present a public address that has been stored in the smart contract.

If you’re slightly experienced with Web3 you quickly will notice the many flaws of our very first approach: the Symfony backend application is ultimately centralized. You could skip the Elixir part alltogether and move Elixir backend interaction code (needed for event creation) to the PHP side. We actually didn’t do so because our Symfony developer felt uncomfortable with it but it’s certainly possible.

Another tricky part of our approach is the usage of React Native: as it turns out running a web3 client that interacts with Ethereum is not the easiest thing to achieve on the native platform: that is mostly due to node.js’ crypto library being incompatible with the web platform and compiling the respective native plugins leads you into the rabbithole of iOS pods and Android JARs to burn in dependency hell. If you really need to interact with Etherum from a web/native client we now can recommend ethers.js, but we didn’t discover that during BREAKOUT week.

We ended up with a working prototype that just ran a simple smart contract like this:

pragma solidity >=0.4.22 <0.6.0;
contract ETHicketEvent {
    address payable hoster;
    
    mapping (address => uint8) tickets;
    
    constructor() public {
        hoster = msg.sender;
    }
    
    function requestTicket(address attendee) payable public {
        require (msg.value > 1000000);
        hoster.transfer(msg.value);
        tickets[attendee] += 1;    
    }
    
    function getTicketCount(address requester) public view returns (uint8) {
        require(msg.sender == hoster);
        
        return tickets[requester];
    }
}

To roughly explain what’s going on here: everybody who’d like to host an event can deploy a new instance of this smart contract thus becoming its recognized owner (hoster = msg.sender). To “buy” a ticket attendees invoke the requestTicketmethod sending along a minimum of one MWei. The ticket price immediately is transferred to the event host. An internal hash table (mapping(address => uint8) tickets) is incremented on each transaction so that one attendee can buy more than one ticket.

The idea was that the centralized Symfony backend would keep track of smart contract instances, effectively allowing event hosts to manage all event details in a centralized way and just utilize Ethereum to sell and maintain “tickets”. Event owners would not necessarily need any knowledge of the blockchain in this concept. As you can see in one of the contracts’ transaction history, this happened several times during Breakout week.

After failing on interacting with Web3 in React Native, we ended up using the brand new React based version of ionic on the frontend and utilized the most well known desktop and mobile (still in beta) Ethereum interaction tool MetaMask aka “The Fox”. Upon startup our mobile optimized web app loads all events from the centralized API endpoint and creates a new Web3 wallet and account by using an injected (in our case: hardwired) private key. From here we could issue requests to the smart contract addresses that the API gave us, effectively being able to “buy” tickets from a fixed user account. We’ve been using the Ropsten testnet via an intermediary infura JSON-RPC node, but we also tested it with our very own geth based Ropsten node — which went equally well. Unfortunately our network didn’t allow us to connect it via Wifi which rendered it unusable for demonstration purposes.

Intermission: Đappcon

The final eye-opener

What we definitely learned: either you go decentralized or you don’t. Having any centralized part in the whole system would break any other. With that in mind I attended Đappcon in August 2019.

A three day event that completely concentrated on the latest developments in the Ethereum world and it was no disappointment. Hundreds of international guests came to my hometown and I suddenly felt very understood — I noticed that we have not been on some esoteric path on a mysterious alien tech stack, but rather didn’t listen well enough to what so many of Đappcon’s attendees already understood: the Web2.0 as we know it is dead, the future already has begun years ago. Writing smart contacts in a way we were doing could already be considered old school. Decentralized Autonomous Organizations are already (more or less) taking over our understanding of incorporated and limited companies as we know it. I’ve met digital nomads that make a living out of building Ethereum apps and they get paid in Ethereum and Dai (an Ethereum backed Stablecoin oriented on USD). That was my personal turning point: I had to make this kite fly and I had to find a team for it.

The ĐOor — an EthBerlinZwei submission

Only one day later the EthBerlinZwei hackathon was about to take off and boy was I ready to write history. I created a pitch to find people to team up with and found three amazing musketeers to join the party: Tam (Berlin/Israel), Ben (Lithuania) and Niels (Hamburg) happily adapted the idea and we started remixing it. In short we wanted to solve the last part of the puzzle:

how to effectively identify someone coming to your event as a valid (and charged) attendee?

That’s why we called our project ĐOor. It’s potentially usable as a “door opener” for any kind of physical and non-physical entry restriction and it consists of three parts:

• event management. Everybody can create a new event and control the event’s attendee list, ticket prices and content data.
• ticket sales / RSVPs. Everybody can discover all created events and signup for them eventually by sending some Ether along as ticket price.
• the bouncer use case. At the door an attendee’s identity is checked against the list of attendees. If she’s on the list, admission is granted.

We decided to go with Solidity smart contracts again but were using OpenZeppelin tools for it: they come with a huge amount of audited contracts that have been proven to work as great foundation for all common application needs. Further we were building our frontend on plain web technologies and chose to use Vue.js as frontend library (which I personally find a rather unfavorable choice because of the unnecessary conventional complexity when compared to React; but that’s a totally different story).

Event management

To create new events users interact with a unique instance of a so called DoorFactory that spawns new ĐOor contracts on their behalf. A creator is the first owner of that contract so all fees will be transferred to his account. Thanks to OpenZeppelin’s premade Ownable base contract, ĐOors can be easily transferred to new owners. Here are the more interesting parts of the code, starting with the Door factory contract:

pragma solidity ^0.5.0;

import "./Ownership.sol";
import "@openzeppelin/upgrades/contracts/Initializable.sol";

contract DoorFactory {
    address[] public doorAddresses;

    event NewDoorCreated(
        address indexed doorOwner,
        address indexed doorAddress,
        string indexed doorName,
        uint ticketPrice,
        bool allowDisposeLeftovers
    );

    function createNewDoor(uint256 _price, 
         string memory eventName, 
         bool allowDisposeLeftovers) 
         public returns(address) 
    {
      Door door = new Door();
      door.initialize(_price, eventName, allowDisposeLeftovers);
      door.transferOwnership(msg.sender);
      doorAddresses.push(address(door));

      emit NewDoorCreated(
        msg.sender,
        address(door),
        eventName,
        _price,
        allowDisposeLeftovers
      );
      return address(door);
  }
  ...
}

and the spawned Door “instance” contracts:

contract Door is Ownable, Initializable {

    string public nameOfEvent;
    uint public ticketPrice;
    
    uint attendeesCount;
    uint256 shares;

    enum AttendanceTypes { NONE, REGISTERED, ATTENDED }

    struct UserStruct {
        AttendanceTypes ticketStatus;
    }
    mapping(address => UserStruct) public users;

    function initialize(uint256 _price, string memory eventName)
             public initializer payable
    {
         ticketPrice = _price;
         nameOfEvent = eventName;
    }
    
    function buyEventTicket() public payable 
    {
        require(users[msg.sender].ticketStatus == AttendanceTypes.NONE, 'User already has a ticket');

        require(
            msg.value == ticketPrice,
            "msg.value does not meet the ticket price."
        );

        this._owner.transfer(msg.value);
        users[msg.sender].ticketStatus = AttendanceTypes.REGISTERED;
    }
    ...
}

Attendance

Every client application (e.g. our Vue frontend) can now discover all existing door contracts that the factory has created by using its contract address, the contract’s ABI and calling its getAllDoors method. Once discovered one can call the Door’s buyEventTicket method and send an appropriate ticket fee in Ethers. Each door keeps track of its own attendee list and relays the money directly to the current door owner.

Ben introduced a twist to the story that goes a little deeper: when you mark an event/door as “withdrawable”, attendees have to pay an upfront deposit, even if the event is free to attend (not unrelated to meetup.com’s idea). As soon as the owner identifies an attendee as having attended the event, the attendee has the right to get his deposit back. That’s quite a clever strategy to decrease no show-rates: if you don’t go to a meetup, your deposit is lost.

The quite popular “kickback” project came up with this idea first and ran quite a bit of events already pushing down no show rates to an all time low. Ben’s little withdraw method allows any attendee to withdraw his deposit after he had been marked as attended by the host and the event officially has ended.

Proof of Attendance

And here comes the hard part. How do you prove that someone attended an event in person? First, standing at the door the attendee has to somehow be able to present her public key since that’s the piece of data that a ĐOor contract saves as indicator for her “ticket”. But what keeps her from simply giving a friend (or the whole world) her public key? After all it’s even stored publicly visible in the blockchain’s history so everybody could simply pick up a public key that had signed on and try to get into the event with it.

The simplest prevention strategy would be to mark a public address that passed the door as “attended” and block every other attendee who tries to use the same address again. However that would mean that we’re now potentially excluding the true ticket holder: first come first enter never has been a good idea, except in biology.

A quite promising variant is the issuing of ERC20 tokens as event tickets. Each token would represent one ticket and to get into the location you simply transfer your token to the bouncer’s wallet. As soon as that transaction is confirmed, the door opens. Good idea, but what keeps you from simply transferring that token to a friend of yours. Shouldn’t be an issue for free events but for exclusive events that might not be exactly what you want. Non fungible ERC721 tokens (NFTs) can remedy that issue but they’re contradicting the reality: besides the number printed on it, a ticket for the next Madonna show is interchangeable. The good thing about NFTs is: you could seamlessly prove which way it went and it’s absolutely unique to the first issuer and owner. A great idea for secondary ticket market applications actually but here’s the caveat: Ethereum transactions are slow.

While on Ropsten testnet it takes around 30 seconds until a transaction can considered as confirmed, on Ethereum mainnet one token transaction might take up to 2 minutes (avg block time of 15s x 7 confirmations). If you’re serving free coffee at your ĐOor that might be an option for someone but surely not for the masses.

As it turns out, asymmetric cryptography comes with a builtin solution to this problem and it’s private key signatures.

Open, Sesame

So here’s our solution: when an attendee knocks at the ĐOor, the bouncer creates a random 4-digit string and presents it to the attendee. The attendee signs that short lived shared secret with his private key and creates a QR code containing the signature. The bouncer scans the QR code on the presenter’s device and calls Ethereum’s ecRecover method with the random string known to him.

This method will yield the public key of the attendee standing at the door in this moment. He can check that the public key is known to the ĐOor contract (which is a matter of milliseconds since it doesn’t include a status change) and trigger a new transaction to set the addresses state to “attended”. Since all operations happen either offchain or are just reading contract state, the overall verification process takes not longer than 5 seconds and is even faster if the bouncer keeps a local copy of all attendee addresses.

That’s the rough summary on what our team achieved at EthBerlinZwei. Our DevPost submission contains links to all the code and our preliminary demos.

Stefan Adolf on Twitter

We built ĐOor during @ETHBerlin: a #decentralized door opener that manages events and admissions. Attendees prove their identity by signing a random secret offchain. Thank you @Dakavon @mr_hemulin &amp; @BenasZabita for making it happen :) https://t.co/R1iUVIMMIL @OpenZeppelin

Team Meeting: event management and discovery

While the ĐOor idea is a fabulous tool to check an attendee’s “ticket” to gain admission, one question remains open: should we really manage events and their metadata on that platform?

If we did so, event hosts were supposed to use a frontend owned by us to add new events by a factory provided by us in a format that we have to come up with. We’d finally end up as the next meetup.com as well — with a decentralized database but still with a central concept how event data should look like.

Time for yet another hackathon: our completely new team (with me being the only participant who joined from team ĐOor, the others being Sascha, Jean Daniel, Sebastian and Hendrik) at Diffusion 2019 (October 20th) wrapped their minds on how we could make events discoverable without owning or defining them. Since it’s hard to convince a completely new team to hack on something the team before had left behind, we went with the new name “Team Meeting” and started from scratch.

Use what’s there: the semantic web

For the data part we came up with the idea to go with what’s already available, and as it turns out the ideas of a semantic web is very alive. Most likely out of SEO reasons many sites that display and host event pages are enriching their markup with micro formats or structured data — small but well defined pieces of information, either provided as additional attributes inside the markup, meta headers or meta blocks hidden in script tags and formatted as JSON-LD.

A browser visiting a page that contains schema.org microdata formats immediately recognizes that the user is browsing an event page and could extract all meta data from it: Title, venue location or opening times are all available in a machine readable format. Good for us that meetup.com and eventbrite make heavy use of it: they expose lots of event content on their event pages hoping that GoogleBot makes sense of them. Here’s an example of JSON-LD formatted metadata on eventbrite for the upcoming React.Day:

So why should be GoogleBot the only client to make sense of that data?

We decided to write a Chrome extension that detects microdata formats and extracts event data from pages. As soon as it detects an event, it offers the user an “RSVP” action (or potentially a “buy ticket” button if the event is not free). Once a user hits that button, we’re transmitting the event data to a free, decentralized and globally storage: IPFS.

Thanks to the alpha version of ipfs-js that works without the need to run your own or connect a dedicated IPFS node — peer discovery and upload happens only in the browser (ipfs-js just keeps some constant root nodes to discover peers). Once on IPFS each event gets a unique content identifier, the CID. After some seconds the information is stored on the worldwide decentralized storage network (e.g. https://ipfs.io/ipfs/QmevnNxM2qTRJp6DFdq7Xh2g5GoMXWLoNGAKSjTtKQRv1w)

Since we cannot access a MetaMask / web3 context from within the browser extension’s scope, we’re redirecting the user to a statically hosted Đapp landing page that requests a web3 context and is preloaded with the event page’s original URL and its IPFS CID. Here the user can finally sign up for the event by sending a small transaction to dedicated smart contract’s rsvpForEvent methods:

pragma solidity ^0.5.8;

contract Meeting {

struct EventStruct {
    address[] rsvps;
    bytes cid;

bool isCanceled;
  }

mapping(bytes32 => EventStruct) public events;
mapping(bytes32 => uint8) public meetups;
mapping(bytes32 => uint8) public attendees;

event MeetupCreated(string url, bytes cid);
  event MeetupRSVPee(string url, address attendee);

function rsvpForEvent(string memory url, bytes memory cid) public {
    bytes32 id = keccak256(abi.encode(url));

    meetups[id] = meetups[id] + 1; // cheap existence check

    if (meetups[id] > 1) {
      events[id].rsvps.push(msg.sender);
    } else {
      emit MeetupCreated(url, cid);
    }

    bytes32 attend = keccak256(abi.encode(url, msg.sender));
    attendees[attend] = 2; // code for attending

    emit MeetupRSVPee(url, msg.sender);
}

function rsvpForExistingEvent(string memory url) public {
    bytes32 id = keccak256(abi.encode(url));
    require(meetups[id] > 0, "event needs to be created first");

    bytes32 attend = keccak256(abi.encode(url, msg.sender));
    attendees[attend] = 2;

    emit MeetupRSVPee(url, msg.sender);
}

function isAttending(string memory url) public view returns (bool attending) {
    attending = isOtherAttending(url, msg.sender);
}

function isOtherAttending(string memory url, address identity) public view returns (bool attending) {
    bytes32 attend = keccak256(abi.encode(url, identity));
    attending = attendees[attend] == 2;
}

function isRegistered(string memory url) public view returns (bool registered) {
    bytes32 id = keccak256(abi.encode(url));
    registered = meetups[id] > 0;
}

function countAttendees(string memory url) public view returns (uint users) {
    bytes32 id = keccak256(abi.encode(url));
    users = meetups[id];
  }
}

That’s a more or less working contract to anchor new events and their attendee list on the ledger. What’s missing is the discovery part (show me events nearby ‘Berlin’). For this we had to dig slightly deeper into the box of secrets:

The Graph: derive a GraphQL API from Ethereum events

Assume you’d like to find nearby events only by iterating Ethereum transactions and fetching their related content one by one. If the amount of stored events grew large it’d be a massive overhead to do so on every request and that’s why one has to come up with a (potentially centralized) projection that persists the event store’s generated state in a queryable database. If we were only to index the event data on IPFS, OrbitDB could be a suitable option but since we are about to update the projection as soon as an RSVP occurs, we decided to go with the The Graph.

The Graph is a YML-configured GraphQL-SaaS / self hosted service that listens on events on Ethereum and IPFS and updates its internally persisted state according to the event data. You can write handlers and mappings that are invoked as soon as an event is triggered and within these you can do nearly anything you need to fetch the data that’s related to the event. The Graph mappings are written in AssemblyScript, a subset of TypeScript and compiled to an executable WASM binary.

There are two mandatory parts to configure and build your Graph instance: first you’d want to define a GraphQL Schema definition for the projected entities. The Graph is inferring an ORM like entity layer that you can use inside your handlers to read and write entities to The Graph’s provided “store” abstraction. The most important part is the “subgraph” configuration that The Graph uses to setup event listeners for your smart contracts and bind your custom handlers to events and entities:

specVersion: 0.0.2
schema:
  file: ./schema.graphql
dataSources:
  - kind: ethereum/contract
    name: Contract
    network: ropsten
    source:
      address: "0xe742EF468584506C32B86541d0c3d4878857Af66"
      abi: Contract
    mapping:
      kind: ethereum/events
      apiVersion: 0.0.3
      language: wasm/assemblyscript
      entities:
        - MeetupCreated
        - MeetupRSVPee
      abis:
        - name: Contract
          file: ./abis/Contract.json
      eventHandlers:
        - event: MeetupCreated(string,bytes)
          handler: handleMeetupCreated
        - event: MeetupRSVPee(string,address)
          handler: handleMeetupRSVPee
      file: ./src/mapping.ts

Being configured like this, The Graph will setup services that listen on MeetupCreated or MeetupRSVPee events of the Contract contract and feed all that data into a hosted database (which actually uses Postgresql under the hood) with an automatically generated GraphQL API layer on top of it. The frontend can simply ask for deep graph data, e.g. to filter upcoming events with specific tags in a certain city.

Our final Devpost submission for “Team Meeting” can be found here. Currently the code is still in hackathon state but works more or less as explained above.

Consolidation & Conclusion

What we were building and what we’re about to build

All the code and facts that you’ve seen above are the result of three weekends without sleep, achieved by around 10 people who never have met before in their lives. So please bear with us: this is not a working piece of software yet.

At the time of writing we’re in the middle of figuring out how we continue this project. We most likely stay on the Ethereum chain, even though there’s a lively discussion going on whether Parity / Substrate, NEAR, elastic Eth Sidechains or Eth2.0 / Serenity are the stacks to wait for or build on. Personally I’d happily stay with the proven Ethereum stack and embrace MetaMask as “identity” wallet and mandatory dependency for interactions.

We will surely invest some energy in the event detection / storage / discovery part of the whole story since this is what the most owned, federated and siloed part of the current meetup/event ecosystem is. The people behind our ĐOor idea want to take it a step further and add more close-to-event features (e.g. Kickback-like RSVP deposits that will be transferred back to their origin as the proof of attendance had taken place) whereas Team Meeting prefers to decouple functionality as much as possible to just help with the plain chain anchored event data base.

If you want to be part of the discussion or would like to dig through or contribute to our code or you want to fork it and build your own new meetup.com: go ahead, the way is free for you — here’s our “ ĐOor” organization that currently maintains both our ĐOor and Team Meeting repos: https://github.com/d0or . If you’d like to support or integrate us in any way, don’t by shy and contact us.

After the Meltdown: rethinking event management platforms. was originally published in t14g on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hackathon #7 this year introduced me to the unknown waters of health tech & machine learning. I’ve always tried to get myself into these areas, so I’m glad I finally have been forced to wrap my head around them. The organization team (thank you impactfarm for making it outstanding) told us four weeks in advance about the challenge they had in mind for us — and thankfully they also came up with a team name: From September 14 on, we could refer to ourselves as the “Turbiners” (which is slightly incorrect, since two of us were absolutely unaffiliated with Turbine). So, we had four weeks of time preparing our project — which is still hard when you’re on a full-time job — and it read: “intelligent claim management in the digital health ecosystem”.

Now, what you may not be aware of: Fraud is a highly underrated and very relevant topic in the health industry. According to a McKinsey study from 2017 there’s a saving potential for health insurers in Germany of up to half a billion euros a year — only by checking reimbursement claims by care providers (doctors, hospitals, hospices etc.) more thoroughly. As it turns out, 70% of all claims need to be checked, but only 8–10% of the potentially fraudulent cases are finally identified and corrected. If that doesn’t sound like a good case for Machine Learning, what does?

Since our team had been assembled quite randomly, we were extraordinarily lucky to have had Elena Williams in our team. She’s currently studying data science in Hamburg and could contribute much of her knowledge into our project. Around two weeks before the hackathon we were looking for data sets that could help us and eventually Elena came up with this one. It contains 130.000 claims by more than 5400 providers and has been examined by experts who identified the fraudulent entries. What’s important to understand: Fraud can only be observed on a provider level. The unique claims are pretty much unobtrusive, so any model we could come up with only would operate on providers and never on particular claims.

Bayer Karriere on Twitter

„So how do you feel on the second day of the #healthhackathon19, Elena?!" https://t.co/Bl8n4RRMXR

The original notebook takes three approaches to analyse the dataset: Logistic Regression, Random Forest Classifiers, support vector machines and an auto encoder. They reached a predictive accuracy of anything between 50–90%. To boost the accuracy further, Elena tried to figure out better features to train the model and relied on a Keras Deep learning model with four layers. According to the training evaluation she reached an accuracy of 93% in the end which is quite outstanding.

In the meantime, the rest of the team concentrated on making the prediction model usable — seeing is believing, right? So I created a fresh React app, imported all the test data into a Sqlite database (sic) and wrote a Flask micro API that’s capable of selecting all claims for a given provider. It also comes with an endpoint to call the predict function of the trained model. I noticed quite early that this is not a simple task: All these data scientists use their highly interactive Jupyter notebooks for one reason or another, but that’s not something that you want to build a “reliable” service on (do you?). So most of our backend work consisted in transferring Elena’s data transformation and feature extraction code into a plain Python backend.

The plan was to upload an Excel / CSV-file with a batch of beneficiary / claim data on the frontend, translate it into the presentation that Elena’s model would expect and run the prediction on it. Thankfully our junior dev Sascha took care of the upload part, so I could concentrate on the integration. I made one observation that could be helpful for others: While Sqlite comes with great support of automatic CSV imports it unfortunately translates a string value of “NaN” to “NA” (which might be the NaN-representation of Sqlite, who knows). When reading this data with Pandas again, it interprets it as string. Once we figured that out, following up the other 250 cells was close to a piece of cake. Python people might know that but let me repeat: The tensor manipulation features of Panda’s DataFrame are simply outstanding! If you happen to do any data analysis in any language — stop here and switch to Python, it will save you days of data manipulation.

A major issue we weren’t able to figure out is the scaling of predicted values. Elena’s model performed nicely on training and testing data sets but calling the prediction on a single data set (consisting of around 60 claims, derived from the original training data) just ended up in an array of unusable float data — in the end, she didn’t develop a binary classifier, but rather a predictor that yields a certain probability of having identified a fraud. Unfortunately, without a clear output it wasn’t possible for us to demonstrate our model’s accuracy, but I’m pretty sure that’s mainly due to our missing experience.

If you’d just like to get a feeling for all achievements, here is a deployment for you (it’s currently asleep, give it 30 seconds to wake up & another 20 seconds to download the database from my S3 bucket): https://turbiners.netlify.com. The codebase is split into a Python backend and a React frontend. It looks so nice because I’ve been using Grommet JS for styling.

Another part of the jury’s evaluation was a business model canvas for our case. Now, since I’m a down-to-earth, glue-level, hard rock listening developer I must admit that my business development skills have degraded and I still have the strong opinion that “business” and “hackathon” are never a good match. I’ll still share a few of our ideas and would like to thank Florian Schulze, Turbiners’ team member #4 for the effort he took from our shoulders by starting off ideas:

• Value proposition: we want to build a digital claim management service (running on our side) and an obfuscator / anonymizer service (running on the insurance / client’s side).
• Our key partners would be insurance auditors with lots of experience in detecting medical claim fraud cases.
• Our primary customer segments would be German health insurance companies and their attached consultancies.
• As sales channels we identified health conferences and SaaS solution marketplaces (e.g. offering a blackboxed service instance of us on customer operated dedicated AWS instances).
• After quite some discussion, we agreed that our preferred business model would be to take a 0.5% share of all analysed claim reimbursements files (which could add up to around €50–100mn revenue / year depending on quality of prediction and market share)

Here’s our final pitch deck:

Some miscellaneous takeaways and side notes.

• The winning team (consisting of only 1 member) in our category has absolutely earned his prize: He threw together an Android app, a Blockchain, a VR channel and MongoDB and built an app that first tells you which exercise to execute and then scans your body movements to identify that you’re doing it right. Once done, it stores your achievement on a chain and registers your activity in Mongo. I’m dead sure that it took most of the four weeks of preparation to put all these pieces together, and I was quite impressed by his demo.
• The other category dealt primarily with machine support in “real” health applications, e.g. ophtomal… eye diseases. One team certainly stood out: They used some weird looking lens concept to scan your eyeball. With a little machine learning / image classification attached, they were able to identify major health conditions within just a fraction of the costs a “real” medical device would need.

Contacts and Takeaways

The most important reason why I personally wanted to join the health hackathon, though: I’ve been looking for contacts, inspiration and validation of the real world use case I’m currently working on at Turbine. That is: storing a patient’s medical record and its access rights on a decentralized ledger. And I have not been disappointed:

Several parties, among them four co-workers of Berlin’s Charité, lawyers, doctors and consultants strongly confirmed my assumption: There is absolutely nothing like a shared digital patient file in Germany. All approaches toward it are heading into the direction of either medication plans, fitness tracking or “eGK” applications that collect and store data that a patient collects himself (e.g. by tracking her blood pressure). It’s astonishing, but every time I roughly illustrated our idea everybody became very excited and immediately offered their full support.

Conclusion

This is what a conference and hackathon should look like. The food could’ve been better (no complaints about bad food if it’s for free, yes, I’m already sorry), the beer could’ve been more plenty, the surround sound of all four conference panels could’ve been less annoying and the unnecessary artificial “pressure” that the main hackathon sponsors have been building up upfront was unnecessary. But besides that, we all had a lot of fun! :) Next up: Diffusion 2019!

Turbine goes: XPOMET Health Hackathon 2019 was originally published in t14g on Medium, where people are continuing the conversation by highlighting and responding to this story.

Wo waren Sie…

…als die Kryptowährungs-Kurse Ende 2017 explodierten? Als der Wert eines einzigen Bitcoins die Schallmauer von 20.000 Dollar durchbrach? Erinnern Sie sich an den tiefen Fall wenige Tage später und das Durchschreiten des Kurstiefs im Frühjahr 2019? Haben Sie eventuell Geld in “Cryptotokens” investiert, in Ihrem Freundeskreis über den ökologischen Impact des Bitcoin-Minings diskutiert, bei ICOs und vielversprechenden Token-Vorstellungen mitgewettet? Und sich dabei immer wieder auch gefragt: hat das alles einen realen Nutzen? Oder standen Sie auf der Gegenseite und haben das Ganze stets als anachronistischen Tulpenzwiebelwahnsinn abgetan, ausgelöst von ein paar neurotischen Visionären aus Fernost, immer auf der Jagd nach dem nächstgrößeren unhaltbaren Werteversprechen, um unbedarften Investoren das Geld aus der Tasche zu ziehen?

Ganz gleich wo Sie stehen oder standen: die maßgebliche Technologie hinter Kryptowährungen ist alles andere als eine substanzlose Erfindung eines unbekannten Philanthropen mit japanischem Kunstnamen. Die Blockchain und ihre Varianten sind eine Erfindung, die man nicht nur ernst nehmen, sondern analysieren, bewerten und für sich nutzbar machen sollte. Ganz abgesehen davon, dass mancher den weltweit verteilten “Kassenbüchern” (frei übersetzt aus dem englischen “Ledger”) zutraut, das Wertesystem westlicher Demokratien nachhaltig erschüttern zu können, kann man unvoreingenommen feststellen: sie ermöglichen einer Gruppe von Teilnehmern, die sich nicht kennen und daher auch nicht im Hinblick auf ihre Absichten vertrauen können, miteinander zu interagieren, indem sie Geldwerte transferieren oder langfristige Übereinkommen treffen. Im folgenden wollen wir die Technologie und die Gedanken hinter Bitcoin vorstellen, ihren Nutzen diskutieren und zeigen, dass sie weiter fortgeschritten und marktfähig sind, als mancher vielleicht denken mag.

Währung kommt von Wahrheit

Eine Währung ist ein Instrument des Vertrauens: wenn Sie sich mit einem Bauern darauf einigen, dass er mit Ihnen ein Ei gegen eine Glasmurmel tauscht, sind die Werte “Murmel” und “Ei” ineinander konvertierbar. Wenn jemand nun einen Weg findet, äußerst günstig viele Glasmurmeln herzustellen, wird der Bauer irgendwann mehr als eine Murmel für ein Ei verlangen. Die möglicherweise groteskeste Version eines solchen Geldsystems sind die tonnenschweren Rai-Steinscheiben, die auch heute noch Inhaber von Immobilien nachweisen.

Glasmurmeln, Steinscheiben und Euro-Banknoten haben für die meisten Marktteilnehmer selbst keinen besonderen Wert, sie stehen nur symbolisch für Eier, Kraftfahrzeuge und Netflixserien, die man damit konsumieren kann. In einer ökonomischen Zivilisation sind wir auf solche Symbole des Vertrauens angewiesen, um beliebige Werte ineinander überführen zu können, Handel zu treiben und durch Verleih und Zins Wachstum zu ermöglichen. Banken und Regierungen fallen dabei seit der Erfindung des Geldes besondere Rollen zu: sie schaffen die Regeln für die Währung, sie garantieren mit ihrem Namen und ihrem Vermögen für die Einlagen der Marktteilnehmer und sie steuern die Verfügbarkeit, den Zins und den Verleih von Geld; sie sind gewissermaßen der Ursprung, aus dem sich das Währungssystem entwickelt. Sie garantieren, dass man für einen Schein mit aufgedruckter Zahl einen halbwegs stabilen Gegenwert erwarten kann, indem sie die Spielregeln des Systems festlegen. Seitdem sich in den Siebziger Jahren das Bretton Woods-System, gemäß dem jeder US-Dollar mit einer bestimmten Menge Gold gedeckt sein musste, selbst außer Kraft setzte, können alle Institutionen, die ihr Geld gegen den Dollar konvertieren, nahezu beliebig neues Geld erschaffen, indem sie es z.B. über ihre Zentralbanken zu einem bestimmten Zinssatz verleihen. Solches Geld bezeichnet man im Investorensprech als “Fiat”-Geld, aus dem Lateinischen “Es werde” (Genesis 1, §3).

Sobald man sich auf eine Bezeichnung der Währung (Glasmurmel, Euro oder Bitcoin) geeinigt hat, ist der Weg zu einem giralen Geldsystem nicht weit: Sie können einer Bank einen Hundert-Euro-Schein anvertrauen und der Bankangestellte wird in einem Buch hinterlegen, dass Sie jetzt 100 Euro Guthaben auf ihrem Konto haben. Sobald Sie einen Teil Ihres Guthabens gegen einen anderen Wert tauschen möchten, teilen Sie der Bank mit, welchem Konto Sie einen gewissen Betrag gutschreiben möchten, weisen dies dem Empfänger nach und können dafür die entsprechende Gegenleistung erwarten. Kommt der Empfänger seinen bezahlten Pflichten nicht nach, können Sie mit Hilfe ihres bei der Bank bestellten Kontoauszugs glaubhaft nachweisen, dass die Transaktion zu einem bestimmten Zeitpunkt stattgefunden hat. Der uneingeschränkte Fluss des Geldes, bestehend aus Einzeltransaktionen, ist die Grundlage jeder Art von wirtschaftlicher Transaktion; Bankkonten dienen als Nachweis für Absichten und Leistungen.

Das im englischen Sprachraum gebräuchliche Wort für Währung ist “currency”, was den Sinn des Geldes viel besser verdeutlicht als der deutsche Begriff, der mutmaßlich der “Wahrheit” entlehnt wurde, tatsächlich aber auf die “Gewährleistung” zurückgeht: Geld ist ein transaktionales Schmiermittel zur Steuerung von Warenströmen, Werten und Dienstleistungen. Es besitzt keinen stehenden Wert, sondern ist nur ein volatiles Werkzeug, um Besitztümer zu tauschen und Ansprüche geltend zu machen.

Vertrauen und Vertrauensbruch

Geld ist in unseren westlichen Kulturen derart fest verankert, dass wir kaum noch merken, dass das Vertrauen in Banken, Geld und Regierung nur in unseren Köpfen existiert. Die Banken- und Finanzkrise ist nur spurlos an den meisten Bürgern vorbeigezogen, weil die EZB ihren gewaltigen Vertrauensvorsprung in eine Geldflut ummünzte, um das Euro-Einlagensystem zu stützen und seitdem mit Minimalzinsen die Wirtschaft halbwegs am Laufen hält. Aber fragen Sie mal eine enteignete Hausbesitzerin im amerikanischen Mittelwesten, einen Lehmann-Banker oder einen ehemaligen Deutsche Bank-Vorstand, wie die das sehen.

Unlautere Marktteilnehmer sorgen dafür, dass sich herkömmliche Währungssysteme erschüttern lassen; Landes- und Zentralbanken sowie der Internationale Währungsfonds werden seit der Krise nicht müde, neue Kontrollinstrumente zu erfinden und per Gesetz zu installieren, um den weltweiten Kapitalmärkten Regeln aufzuerlegen. Sobald systemrelevante Teilnehmer wie Italien, Venezuela, China oder eine bayerische Immobilienbank anfangen, sich über diese Regeln zu ihrem eigenen Vorteil hinwegzusetzen, sind alle vertrauensstiftenden Bemühungen der Institutionen wertlos. Das System steht auf Messers Schneide, Populisten untergraben weltweit das geborgte Vertrauen in den Staat, Banken können unter der anhaltenden Nullzinspolitik kaum noch genug erwirtschaften, um die Einlagen ihrer Kunden zu garantieren; es lohnt sich für sie einfach nicht mehr, Geld zu verleihen und schon gar nicht mehr, die Girokonten ihrer Kunden zu verwalten.

Die letzte Chance auf Rendite: riskante Hebelwetten auf die Zukunft

Um überhaupt noch Geld mit Geld zu verdienen, bedarf es Finanzprodukten mit Hebelwirkung: Futures, Hedgefonds, Derivate, Optionen und Obligationen. Da es auch mir schwerfällt, sie im Ansatz zu verstehen, möchte ich mich hier nicht zu weit mit Erläuterungen ihrer Funktionsweise aus dem Fenster lehnen. Im Kern geht es aber bei allen diesen Ideen um die simple Tatsache, dass man mit einer “Wette” auf den Eintritt eines Ereignisses Geld verdienen kann.

Einfaches Beispiel: ich wette mit Ihnen, dass ein Liter Superbenzin am 21. August 2021 zwei Euro kosten wird. Ich garantiere Ihnen, dass ich Ihnen diesen Liter Superbenzin an ebendiesem Datum für genau zwei Euro verkaufen werde und fixiere unsere Absprache auf einem Zettel, den ich Ihnen heute für zwei Euro verkaufe. Wenn das Benzin in zwei Jahren 2,50 Euro kostet, haben Sie 0,50 Euro gewonnen, kostet er dagegen nur 1,50 Euro, gewinne ich 0,50 Euro.

Anstatt den Zettel zu behalten, können Sie ihn aber auch morgen für drei Euro an einen pessimistischen Bekannten verkaufen, je nachdem, welchen Benzinpreis Sie in ihrem Kaffeesatz lesen. Je näher der Stichtag rückt, desto wertvoller oder wertloser wird der Zettel, je nach Sichtweise. Wenn Sie sich beim Kauf des Zettels mir gegenüber sogar verpflichtet hätten, den Liter Superbenzin für diesen Preis abzunehmen, kann es je nach Benzinpreis für Sie ein ziemlich einträgliches oder gefährliches Geschäft werden. Diese Art der terminierten Verbriefung von Preiswetten ist ein tagtäglich millionenfach gehandeltes Wertpapier namens “Termingeschäft” und maßgeblich für die Schwankungen des Spritpreises an Tankstellen verantwortlich. Das Verhältnis zwischen dem gehandelten Wert des Papiers und dem realen Wert des zugrundeliegenden Geschäfts ist der “Hebel”, mit dem Rendite oder Verluste berechnet werden.

Abseits der Frage, ob Sie diese Art von Geschäften für verwerflich halten und am liebsten gleich den modernen Kapitalismus abschaffen wollen, möchte ich Sie zu der Überlegung anregen, was an diesem Geschäft im Kern nicht stimmt. Zunächst einmal das Vertrauen: wissen Sie sicher, dass ich Ihnen 2021 den versprochenen Liter Superbenzin überhaupt aushändigen kann? Dann die Transparenz: der Marktteilnehmer, der Ihnen den Zettel für drei Euro abkauft, wird alles daran setzen, den Preis z.B. durch Verknappung, Zölle, üble Nachrede oder terroristische Anschläge auf 3,50 Euro zu treiben, ohne dass ich nachvollziehen kann, wer dafür verantwortlich ist.

Bankkonten sind ein Konzept für Privilegierte

Ein ganz anderes Problem mit Währungen und Geld entsteht, wenn man in einer Region lebt, in der man nicht auf einen starken Rechtsstaat, Institutionen und Regierungen vertrauen kann. Über 1,7 Milliarden Menschen auf unserem Planeten haben keinen Zugang zu einem Bankkonto — der absoluten Grundlage, um gegenseitiges Vertrauen in Transaktionen aufbauen zu können. Wenn Sie meinen, dass sich auch größere Transaktionen mit Hilfe von Glasmurmeln oder Bargeld abwickeln ließen, dann fragen Sie mal einen kolumbianischen Drogenkurier nach dessen Meinung.

Gleichzeitig liegt in failed States wie Venezuela die reale Bedrohung der permanenten Geldentwertung in der Luft. Sobald ein Staat unkontrolliert Geld in Umlauf bringt oder seine Schulden nicht mehr bedienen kann, verlieren seine Bürger und internationalen Partner schlagartig das Vertrauen in das bunte Papier, das er einmal Währung nannte; in Venezuela lag die Inflationsrate 2018 deswegen bei 130.000 Prozent (das ist kein Komma!) und daran ist weder die CIA noch der schwankende Ölpreis schuld, sondern ein massiver, anhaltender Vertrauensverlust von Bürgern in ihre Institutionen.

Bitcoin: ein faires Vertrauenssystem für eine weltweit akzeptierte Währung

2009 kam ein gewisser Satoshi Nakamoto (es ist nicht öffentlich bekannt, wer das ist — möglicherweise sogar eine ganze Gruppe von Entwicklern) auf eine brillante Idee. Er kreierte mit Bitcoin ein nicht beliebig produzierbares digitales Wertesymbol (die Glasmurmel) und erfand gleichzeitig ein vertrauenswürdiges, transparentes Buchhaltungssystem, auf das beliebig viele Teilnehmer gleichzeitig lesend wie schreibend zugreifen können. Spannenderweise fällt der Begriff “Blockchain” in Nakamotos legendärem Whitepaper kein einziges Mal.

Der Kern von Satoshis Idee ist ein lineares Buchhaltungssystem. Doch was würde passieren, wenn wir alle unkontrolliert gleichzeitig in das selbe Buch schreiben könnten? Angenommen, ich würde laut Kassenbuch über einen Bitcoin verfügen und Sie würden mir einen Gebrauchtwagen für diesen Bitcoin verkaufen wollen; In dem Moment, in dem Sie mir den Schlüssel überreichen, schreibe ich in unserem Kassenbuch Ihrem Konto meinen Bitcoin gut. Da es keine zentrale Instanz gibt, die mich daran hindern könnte, schreibe ich nur einen Augenblick später den selben Bitcoin einem anderen Teilnehmer gut, der mir dafür eine wertvolle Mingvase vor die Haustür stellt. Bevor Sie merken, dass aus meinem Bitcoin zwei geworden sind, bin ich mit ihrem Auto und der Vase im Kofferraum bereits über alle Berge. Die Verhinderung solcher “Double-Spends” ist das zentrale Problem, das Blockchains lösen.

Was wir benötigen, um uns gegenseitig ohne jegliches Zutun einer dritten Partei vertrauen und kontrollieren zu können, ist ein System zum fehlerfreien, unfälschbaren und eindeutigen Nachweis meines Kontostands und zur Abwicklung von Transaktionen in einer festgelegten zeitlichen Abfolge. Sie müssen sich hundertprozentig sicher sein können, dass ich beim Abschluss unserer Transaktion über den geforderten Betrag verfüge. Um dieses Vertrauen herzustellen, müssen sich alle Bitcoin-Teilnehmer verbindlich auf die Reihenfolge und Finalität von Transaktion einigen. Über diese Herausforderung, die man als “byzantinische Fehlertoleranz" oder kurz BFT bezeichnet, zerbrechen sich Informationswissenschaftler seit den 1970er Jahren den Kopf — obwohl ich nicht ausschließen möchte, dass tatsächlich ein paar byzantinische Generäle vor einem halben Jahrtausend vor dem selben Problem standen: wie stellt eine beliebig große Gruppe einen Konsens über die aktuell geltende Wahrheit her, wenn jeder genau weiß, dass einige Teilnehmer in der Gruppe ein falsches Spiel spielen und versuchen, zu ihrem Vorteil falsche Daten einzutragen?!

Bitcoin war der weltweit erste Ansatz, der das BFT-Konsensproblem mit Hilfe einer Peer-to-Peer replizierten Blockchain löste — bis heute hat sich dieser Ansatz bewährt, wird von Millionen von Teilnehmern akzeptiert und hat sich millionenfach als unerschütterliches Instrument des Vertrauens bewährt.

Seeds, Hashes, Wallets und Nonces: Fundamente der Blockchain

Um am Bitcoin-Ledger teilzunehmen, benötigt man zuallererst den Seed eines kryptografischen Schlüsselpaars, nicht unähnlich den Schlüsseln, die man zur Kommunikation mit SSH-Servern oder zur GPG-Verschlüsselung von Emails nutzt. Dieser Seed weist seinen Besitzer als Inhaber aller von ihm ausgehenden Transaktionen aus — wer ihn besitzt, hat uneingeschränkte Kontrolle über das Guthaben, das durch die Saldierung aller mit oder gegen ihn durchgeführten Transaktionen ermittelt wird. Der dazugehörige Public Key ist die eindeutige, unveränderliche, öffentliche Bitcoin-Adresse, die für alle Teilnehmer sichtbarer Bestandteil aller Transaktionen ist. Aus diesen Fakten leiten sich zwei grundlegende Eigenschaften der Bitcoin-Blockchain ab:

• “Not your keys, not your Bitcoin”: wer die Kontrolle über seinen Seed verliert, verliert sein Guthaben — wer ihn besitzt, verfügt über das Guthaben. Wird der Seed kompromittiert, hat man gleichzeitig die Kontrolle über sein Konto verloren.
• Bitcoin-Transaktionen sind nicht anonym und ihr Inhalt ist nicht verschlüsselt. Jeder kann alle jemals getätigten Bitcoin-Transaktionen nachverfolgen und damit sehr leicht Rückschlüsse über die Teilnehmer der Transaktion ziehen. Sobald eine öffentliche Bitcoin-Adresse mit einer Person in Bezug gebracht werden kann, kann man unmittelbar feststellen, mit wem und in welcher Höhe diese Person Geld ausgetauscht hat.

Für die sichere Aufbewahrung und die sichere Interaktion mit der Blockchain sind Apps verantwortlich, die man gemeinhin als “Wallet” bezeichnet. Der Begriff ist so malerisch wie irreführend, denn er verleitet zu der Annahme, dass sich die Bitcoins eines Nutzers in seiner Geldbörse befinden. Tatsächlich enthält die Wallet nur den Schlüssel, um die Kontrolle über eine Bitcoin-Adresse und ihr saldiertes Guthaben nachzuweisen.

Ein anderes Vorurteil: um mit der Blockchain interagieren zu können, benötigt man eine vollständige aktuelle Kopie des gesamten Ledgers — derzeit sind das mehr als 250 GB an Daten. Wäre das tatsächlich der Fall, wäre die Technologie schon heute im realen Leben unbenutzbar. Daher kommunizieren Wallets mit öffentlich sichtbaren Nodes, die Kopien der Blockchain vorhalten und vermitteln lediglich vorbereitete Transaktionen dorthin. Wer völlig unabhängig von anderen Teilnehmern mit Bitcoin interagieren möchte und wirklich niemandem vertraut, kann aber auch selbst einen solchen Node betreiben.

Wenn aus dem Nichts Geld entsteht: Proof of Work und Mining

Transaktionen werden nicht einzeln in den Ledger geschrieben, sondern zu Transaktionsblöcken eines begrenzten Umfangs zusammengefasst — derzeit sind das pro Block etwa 1,2 MB, die durchschnittlich etwa 1000–3000 Transaktionen enthalten. Neben den Transaktionen enthält ein Block den Hashwert und den Index des vor ihm liegenden Blocks, sodass man vom Ende beginnend alle Blöcke bis zum allerersten jemals generierten Block (der Genesis) zurückverfolgen kann: so prägte sich der Begriff “Blockchain”. Das wichtigste technische Instrument in diesem Verfahren ist die sichere Hashfunktion (SHA-256), die aus einer beliebig großen Eingangsdatenmenge einen relativ kurzen, eindeutigen Wert ermittelt und bei der kleinsten Veränderung der Daten zu einem völlig anderen Ergebnis führt.

Aber wie stellt man sicher, dass niemand in betrügerischer Absicht falsche oder widersprüchliche Transaktionen in einen Block schreiben kann? Die einfache Antwort: das kann man gar nicht sicherstellen. Man stellt vielmehr sicher, dass sich alle Teilnehmer auf eine Blockchain einigen, die ausschließlich valide Blöcke enthält. Die längste Blockchain, auf die sich alle Teilnehmer einigen können, entspricht dann der “Wahrheit”.

Die Bitcoin-Blockchain enthält hierfür eine eingebaute “Hürde”, die man nehmen muss, um überhaupt einen validen Block zu erzeugen und die auf Grund ihres zeitlichen und rechnerischen Aufwands als “Proof of Work” bezeichnet wird (wir erläutern die Details des Hashcash-Verfahrens an dieser Stelle nur stark vereinfacht, mehr konkrete Details finden Sie z.B. hier und hier). Ein sich berufen fühlender Teilnehmer fügt eine beliebige Menge ihm vorliegender Transaktionen und den Hash eines aktuellen Vorgängerblocks zu einem neuen Block zusammen und berechnet darüber einen ersten Hashwert. An diesen hängt er eine vom Bitcoin-Protokoll vorgegebene, über die Zeit wachsende Anzahl Nullen an (die sogenannte Difficulty) und sucht nun nach einem weiteren Wert (dem “Nonce”), der gemeinsam mit den Transaktions- und Vorgängerdaten dieses Blocks unter neuerlicher Ausführung der Hashfunktion zu ebendiesem Hash führt. Sobald ein passender Nonce gefunden wurde, meldet er den finalen Block an das Netzwerk und bittet alle anderen Teilnehmer um Überprüfung; während das Auffinden des Nonces extreme Rechenleistug erforderte, ist seine Überprüfung gegen den Rest des Blocks eine nahezu kostenlose Operation, sodass ein einmal validierter Block gute Chancen hat, schnell von vielen Teilnehmern im Netzwerk akzeptiert und damit Bestandteil der weltweit akzeptierten Blockchain zu werden.

Doch warum machen sich einige Teilnehmer überhaupt auf die anstrengende und aufwändige Suche nach Nonces für Blöcke von Transaktionen, die nichts mit ihnen selbst zu tun haben? Weil sie sich laut Bitcoin-Protokoll innerhalb ihres neuen Blocks eine festgelegte Summe von Bitcoins gutschreiben dürfen, die dadurch neu erzeugt werden! Derzeit werden aufgrund dieser Eigenschaft des Bitcoin-Protokolls pro Block etwa 12,5 neue Bitcoins “gemünzt”: dies ist ein Beispiel für die entsprechende Output-Transaktion innerhalb des Blocks 593418. Die Kombination aus schwerer Arbeit mit anschließendem Geldregen führte zu der metaphorischen Bezeichnung “Miner” für Teilnehmer, die mit der Lösung des Hash-Rätsels beschäftigt sind.

Bitcoin: Systemische Schwächen

Man erkennt hier schnell eine fundamentale Schwäche des Bitcoins. Da die Inzentivierung der Miner, einen extremen Rechenaufwand zu betreiben, vergleichsweise hoch ist (12,5 Bitcoin lassen sich derzeit in etwa 125.000 Euro wechseln), herrscht unter ihnen eine Stimmung wie am Klondike 1896. Besonders enttäuschend ist, dass der allergrößte Teil des Rechenaufwands, für den sie exorbitante Mengen Energie aufwenden, für den Betrieb der Bitcoin-Blockchain völlig wertlos ist: Aberbillionen von Transaktionshashes werden berechnet und verworfen, sobald ein Miner das Rennen um den nächsten Block gewonnen hat. Mit normalen C/GPUs sind Brute-Force-Suchen dieses Ausmaßes ohnehin nicht zu stemmen; die aktuelle Difficulty des Bitcoin-Netzwerks erfordert den großflächigen Einsatz sogenannter Ant-Miner, spezialisierte Hardware, die ihre Betreiber zu Rechenpools zusammenschließen und die gemünzten Bitcoins untereinander aufteilen.

Niemand kann mit Sicherheit sagen, wie viele dieser Geräte auf der Welt in diesem Augenblick gleichzeitig auf Hochtouren nach Hashes suchen und dabei pro Exemplar bis zu 3000 W aufnehmen. Aktuelle Hochrechnungen vergleichen den Energiebedarf des Bitcoin-Netzwerks mit dem Energieverbrauch kleiner Staaten wie Dänemark oder dem Libanon. Diese leider nicht mehr kostenlos zugängliche Studie und dieser ausführliche Coindesk-Artikel taxieren den Energiebedarf auf etwa 45 TWh/Jahr, was man auf eine Emission von 23 Mt CO²/Jahr umrechnen kann. Eine einzige erfolgreiche Bitcoin-Transaktion ist demnach für 200 kg CO² verantwortlich, genauso viel ein Standardbenziner auf der Reise zwischen Glücksburg und Genf verbraucht.

Jede einzelne Bitcoin-Transaktion sollte daher außerordentlich gründlich abgewogen werden.

Hashraten, Transaktionsgebühren und Geschwindigkeit

Das Bitcoin-Protokoll wurde von Satoshi Nakamoto so entworfen, dass die fürstliche Vergütung der Miner ab einer bestimmten Blockhöhe wegfällt. Alle 21 Millionen Bitcoins sind dann im Umlauf und es können keine neuen mehr entstehen. Ab diesem Zeitpunkt werden Miner lediglich durch Transaktionsgebühren inzentiviert, die Eintragende ihnen für das Mining eines Blocks gutschreiben können. Das tun sie bereits heute: Für die Eintragung dieser privaten Transaktion zahlte ich beispielsweise 0.00007707 BTC Gebühren (etwa 0,75 Euro); das klingt nicht viel, aber stellen Sie sich einmal vor, Ihr Kreditinstitut würde Ihnen die gleichen Gebühren für eine girale Euro-Transaktion abziehen — sie würden schon am nächsten Tag zu einer Bank wechseln, die keine Gebühren erhebt. Zur Stoßzeit des Cryptobooms Ende 2017, zu der die halbe Welt binnen Tagen auf den rollenden Bitcoin-Zug aufspringen wollte, waren einige Teilnehmer sogar bereit, Transaktionsgebühren weit über 50 Euro zu bezahlen.

Hinzu kommt die durchs Blockhain-Verfahren bedingte Dauer der Finalisierung: bis ein Block mit meiner Transaktion durch mindestens 6 spätere Blöcke fest in die weltweit längste Blockchain eingetragen wurde und somit als final bestätigt gilt, können mehrere Stunden vergehen. Eine von ihrem Girokonto ausgehende innerdeutsche Überweisung wird je nach Verfahren und Ziel von Ihrer Bank heutzutage binnen Minuten bestätigt, das zentral gesteuerte VISA-System benötigt dafür sogar nur Sekunden (und verarbeitet zu Stoßzeiten bis zu 50.000 Transaktionen pro Sekunde, Bitcoin schafft in seiner derzeitigen Auslegung und Hashrate lediglich 7–12).

Zur Bezahlung eines Abendessens, einer Tasse Kaffee oder eines Wochenendeinkaufs ist Bitcoin wegen seiner Transaktionsgebühren und -zeiten derzeit nicht geeignet. Stattdessen eignet sich Bitcoin viel besser für kurzfristige Spekulation und zur Wertaufbewahrung und das ist möglicherweise die abschreckendste Konsequenz seiner unkontrollierten Vertrauensbasis. Erinnern Sie sich an die terminbasierten Optionsscheine auf Grundlage des Benzinpreises? Ähnliche Wetten werden derzeit auf den Kurs des Bitcoin abgeschlossen. Wegen unkontrollierbar ausgelöster Hype-Zyklen und externer Effekte, die Anleger in vermeintlich sichere Häfen wie Edelmetalle oder Kryptowährungen investieren lassen, sinkt und steigt der Preis eines Bitcoins im Wochentakt; viele sprechen bereits davon, dass sie ihr Bitcoin-Guthaben als digitales “Gold” betrachten, als relativ immobile, Schwankungen unterliegende, aber dauerhaft wertbehaftete Geldanlage. Bei einer solchen Volatilität würde niemand auf die Idee kommen, sich sein Gehalt in Bitcoin auszahlen zu lassen — man wüsste ja nicht, ob der Lohn in einer Woche noch dazu reicht, um seine Miete in Euro bezahlen zu können.

Es sei denn, der Vermieter akzeptiert ebenfalls Bitcoin und bezahlt mit ihm seine Rechnungen. Dann entfällt nämlich das leidvolle Umrechnen in eine Referenzwährung; und das ist derzeit das größte Akzeptanzproblem von Kryptowährungen und Glasmurmeln: solange wir ihren Wert immer an anderen Werten orientieren, bleiben sie volatil. Das langfristige Ziel der Community lautet daher, die Akzeptanz von Bitcoin soweit zu stärken, dass die Kryptowährung ein akzeptiertes Zahlungsmittel wird. Ohne neue Ideen, Änderungen am Bitcoin-Protokoll und der Unterbrechung des digitalen Goldrauschs der Miner wird das nicht funktionieren.

Anwendungen außerhalb der Token-Economy

» Bitcoin Cash

Eine einfache Möglichkeit, Transaktionsraten von Bitcoin zu beschleunigen und die Kosten für eine einzige Transaktion zu senken, ist die Größe eines Blocks zu erhöhen: Die Komplexität der Hashsuche steigt nämlich nicht notwendigerweise proportional zur Blockgröße. Diese naheliegende Änderung im Bitcoin-Protokoll wurde neben anderen Vorschlägen erstmals im Rahmen des Segregated Witness (Segwit)-Proposoals BIP-91 vorgeschlagen und 2017 intensiv von der Community diskutiert. Das Ergebnis des darauf folgenden Disputs zwischen Minern war ein Hardfork der Bitcoin-Blockchain: da sich bei weitem nicht alle Teilnehmer an den vorgeschlagenen Änderungen beteiligen wollten, teilte sich Bitcoin am 1. August 2017 in zwei Lager.

Wer auf der Blockhöhe 478559 ein Bitcoin-Guthaben hatte, wurde Zeuge einer wundersamen Geldverdoppelung mit ungewissem Ausgang: abhängig davon, welcher Blockchain man folgte, hatte man plötzlich den “echten” Bitcoin oder eine ab diesem Block davon unabhängige Währung namens Bitcoin Cash in seiner Wallet — aus einer Glasmurmel wurden plötzlich zwei! Dies ist der letzte gemeinsame Block auf Bitcoin und Bitcoin Cash.

In diesem Augenblick konnte niemand voraussagen, welche der beiden in Zukunft ihren Wert erhalten würde. Wie im ursprünglichen Beispiel hängt es ja davon ab, ob einem der Bauer ein Ei für eine Murmel verkauft und welche der Murmeln er ab sofort akzeptiert. Viele Inhaber der neuen Währung versuchten in den darauf folgenden Tagen ihre Cash-Coins in Fiat zu tauschen und so sank der Kurs von “Bitcoin Cash” zunächst gegenüber dem Bitcoin stark, stabilisierte sich aber nach dem Platzen der ersten Kryptoblase Ende 2018 auf einem niedrigen Niveau.

Genau diese Stabilität macht Bitcoin Cash zu einer interessanten Alternative für den originären Bitcoin, denn die Transaktionszeiten und -kosten von Bitcoin Cash-Überweisungen sind unter anderem wegen einer Blockgröße von derzeit 32 MB (Bitcoin: 1 MB) deutlich geringer als im Bitcoin-Netzwerk. Besser gesagt: sie wären es, wenn Bitcoin Cash die selbe Dominanz wie Bitcoin erreichen würde. Derzeit werden einfach zu wenige Transaktionen an das Hauptnetz herangetragen, um den Effekt nachvollziehen zu können. Fest steht jedoch: eine Bitcoin-Transaktion kostet derzeit umgerechnet etwa 0,86 Dollar, eine Bitcoin Cash-Transaktion lassen sich Miner nur mit 0,0029 Dollar vergüten.

Bitcoin Cash und andere Hardforks der Bitcoin Blockchain haben in erster Linie das Ziel, die Praktikabilität von Bitcoin zu erhöhen, indem sie Blockgrößen und Mining-Regeln modifizieren. Das finden manche Miner natürlich weniger gut, weil sie nach einem Fork höchstwahrscheinlich Profite verlieren — was man sowohl verständlich als auch in Anbetracht der offensichtlichen Nachteile des aktuellen Bitcoin-Proktolls als egoistisch bewerten kann.

» Lightning Network: Payment Channels für schnelle und kostenlose Off-Chain-Transaktionen

Auch Bitcoin Cash leidet am intrinsischen Problem von Blockchains, die ihre Validierung über eine Verkettung von Hashes bis zum Ursprungsblock vornehmen: Sie können nur wachsen und nie vergessen.

Würden alle Bewohner des Planeten Erde Bitcoin als primäres Zahlungsmittel verwenden und sogar ihre Brötchen, Eier oder Kugeln Eis mit Kryptowährungen bezahlen, stieße jede Bitcoin-ähnliche Technologie zwangsläufig auf das selbe Problem: Skalierbarkeit. Ein paar clevere Köpfe kamen daher — inspiriert von Satoshis ursprünglichem Paper — auf die Idee, ähnlich wie im Bargeldverkehr kleine Transaktionen gar nicht auf der Blockchain selbst zu speichern, sondern sogenannte Payment-Channels dafür zu öffnen. Sie nennen es das Lightning-Netzwerk.

Angenommen, Sie kaufen regelmäßig Eier beim Bauern ihres Vertrauens für einen relativ kleinen Betrag; warum sollte das die ganze Welt mitbekommen? Es wäre viel praktischer, wenn Sie und der Bauer ein eigenes Kassenbuch eröffnen, zu Beginn eine bestimmte Menge von Glasmurmeln auf ein von ihnen beiderseitig eröffnetes Pfandkonto einzahlen (hierfür ist das Multisignatur-Feature der Bitcoin-Blockchain erforderlich, mit dem mehrere Parteien eine gemeinsam kontrollierte Adresse erzeugen können) und von dort ausgehend ihre individuellen Transaktionen abwickeln — jedes Mal, wenn Sie ein Ei kaufen, ziehen Sie ihrem Glasmurmelkonto eine Murmel ab und schreiben es dem Bauern gut, ohne dass die Welt das mitbekommt.

Die Anzahl der Glasmurmeln in diesem geschlossenen System bleibt immer gleich und ohne Zustimmung der jeweils anderen Partei können Sie keine Glasmurmeln aus dem System entnehmen. Damit innerhalb eines Payment-Channels Geld den Besitzer wechseln kann, signieren beide Teilnehmer jede Transaktion, der sie zustimmen, mit ihrem privaten Schlüssel. Kommt es zum Disput, kann jeder Teilnehmer des Channels den aktuellen Saldo (die “Balance”) des Channels zurück in die Blockchain schreiben und damit effektiv den Channel schließen und die Guthaben beider Seiten auf den letzten gemeinsam signierten Stand finalisieren. Im Lightning-Kontext wird dieser Vorgang gerne mit dem “Gang vor Gericht” illustriert: sobald es zum Disput kommt, trägt man die aktuellen signierten Kontostände der unbestechlichen globalen Instanz vor, die sie dann endgültig ins globale Kassenbuch überträgt. Diese Präsentation illustriert recht anschaulich, wie das ganze im Bitcoin-Kontext technisch funktioniert.

Wenn jeder Teilnehmer mit vielen anderen Teilnehmern kleinteilige Payment-Kanäle öffnet, entsteht ein Netzwerk von individuellen Kassenbüchern, die alle durch die übergeordnete Währung Bitcoin gedeckt sind. Um mit einem beliebigen Teilnehmer im Lightning-Netzwerk Werte austauschen zu können, versucht das Protokoll zunächst, einen Pfad zwischen den beiden Beteiligten im Netzwerk zu finden. Existiert so ein Pfad, wird der gewünschte Wert über alle Knoten (“Hops”) geleitet, bis er am Ziel angekommen ist. Da diese Transaktionen nicht Bestandteil des globalen Ledgers sind, sondern alleine von den Signaturen der Teilnehmer abhängig sind, können sie deutlich schneller durchgeführt werden und bleiben frei von Transaktionskosten. Sie sind daher auch für Micropayment-Anforderungen geeignet. Um am Lightning-Netzwerk teilnehmen zu können, bedarf es dedizierter Wallet-Clients und Lightning-Nodes, die Features wie Multisigs, private Signaturen und das Konzept der Payment-Channels unterstützen.

Ein anderer Nebeneffekt von Lightning ist seine Unabhängigkeit von der zugrunde liegenden Blockchain-Technologie, sofern sie Multisignaturen unterstützt. Wenn jemand einen Wert in der Alternativwährung Litecoin transferieren möchte, genügt es, den in Bitcoin umgerechneten Wert durchs Lightning-Netzwerk an ein Kanalende zu verschicken, das selbst eine Ursprungstransaktion in Lightcoin hält — die einzelnen Teilnehmer innerhalb des Netzwerks müssen dafür nichts über Lightcoin wissen.

» Blockstack: Dezentrales Filesystem und im Ledger verankerte Identitäten

Die vermeintlich aufregendste Anwendung von dezentralen Ledgern sind sogenannte Smart Contracts; das ist Code, der während des Mining-Prozesses automatisch ausgeführt wird und darin hinterlegte Geschäftsregeln anwendet. Bitcoin unterstützt dieses Verfahren grundsätzlich im Rahmen der Opcode-Schicht seiner Transaktionen, in Ermangelung einer verständlichen, ausdrucksvollen Programmiersprache und wegen der recht begrenzten Blockgröße sind solche Contracts aber im Bitcoin-Netzwerk derzeit nahezu bedeutungslos. Vielleicht benötigt man aber auch gar keine “dezentrale virtuelle Maschine”, die beispielsweise ein zentraler Bestandteil des konkurrierenden Ethereum-Ledgers ist. Um Applikationen schreiben zu können, die die Ergebnisse von dezentral ausgeführtem Code persistieren, genügt es eindeutig nachzuweisen, wer den Code ausgeführt hat (Identität) und was das Ergebnis der Ausführung war (Persistenz).

Seit 2013 arbeitet das New Yorker Startup Blockstack an einer Infrastruktur, mit der sich solche dezentralen Apps (oder kurz dApps) realisieren lassen. Im Zentrum steht der an Bitcoin gebundene Blockstack Naming Service, mit dessen Hilfe Nutzer ein dezentrales Identitätsdokument (DID) mit Hilfe einer speziell für diesen Zweck generierten Wallet in einer Bitcoin-Transaktion verankern. Solange man seinen Key nicht verliert, kann man sich damit lebenslang eindeutig als Person ausweisen.

Um gegenüber Dritten die Glaubwürdigkeit der realen Identität zu verstärken (das kann je nach Anwendungsfall sinnvoll oder gefährlich sein), erlaubt Blockstack die Anreicherung der Identität mit sozialen Proofs: indem man z.B. einen speziellen Tweet zu einer bestimmten Zeit absetzt, kann man gegenüber dem Protokoll nachweisen, dass man ein Twitter-Profil kontrolliert und somit halbwegs glaubwürdig nachweisen, dass man tatsächlich die Person ist, für die man sich ausgibt.

Der einfachste Weg, um mit seiner Identität zu interagieren, ist die ebenfalls dezentrale Blockstack-App. Lassen Sie sich von der augenscheinlich zentral gesteuerten Webseite im Browserfenster nicht täuschen: die Applikation selbst lässt sich völlig unabhängig von einem bei Blockstack beheimateten Server starten und interagiert potenziell autonom mit einem Bitcoin-Node. Meine persönliche Blockstack-Identität ist z.B. hier öffentlich einsehbar und seit März 2018 in der öffentlichen Bitcoin-Blockchain verankert.

Sobald man über eine nachweisbare Identität verfügt, kann man sie dafür nutzen, sich gegenüber dezentralen Applikationen auszuweisen und sich bei ihnen anzumelden. Das hat einen gewaltigen Vorteil gegenüber den zentralen, “federated Logins” a la “Login mit Facebook”: Anmeldungen und Interaktionen innerhalb einer Applikation können nicht getracked werden und die von der Applikation gespeicherten Daten können nicht ohne Zutun des Anwenders mit einer dritten Partei geteilt oder zu anderen Zwecken analysiert werden. Blockstack nennt dieses Merkmal bildhaft “Applications that can’t be evil”.

Neben der Verankerung von Identität bietet die Blockstack-Platform unter der Bezeichnung “Gaia-Hub” einen dezentralen Storage-Layer an, der sich noch in der Testphase befindet. Sofern man dem Unternehmen selbst vertraut, kann man sich einfach an den verteilten Storage-Hub von Blockstack anschließen und kommt damit derzeit in den Genuss eines virtuell unendlich großen Speicherplatzes. Wer hingegen die vollständige Kontrolle über seine Daten behalten möchte, kann selbst einen Gaia-Knoten betreiben; derzeit werden Cloud-Dienste wie AWS S3, Azure Blob Storage und GCP unterstützt, man kann aber auch einfach das Filesystem eines Servers anschließen, dem man selbst vertraut. Alle Daten, die dezentrale Applikationen im Namen des Nutzers speichern, landen auf der vom Nutzer kontrollierten Gaia-Instanz. Der Missbrauch von Profildaten, geheimen Dateien, Fotos oder Nachrichten ist daher ausgeschlossen, sofern der vom Nutzer gewählte Speicherort nicht kompromittiert ist; obwohl dieses System weit von der Vorstellung eines vollständig verteilten Dateisystems wie z.B. IPFS entfernt ist, bietet es mit einfach Methoden Sicherheit, Skalierbarkeit und Privatsphäre für dezentrale Applikationen.

Auf Grundlage von Identität und verteiltem Speicher lassen sich schließlich Applikationen programmieren, die im Browser des Nutzers laufen und dennoch über dezentrale Merkmale verfügen. Blockstack inzentiviert Entwickler mit seinem “App-Mining”-Programm. Das klingt nach Blockchain, hat aber nichts mit “Mining” zu tun: stattdessen wählt das Unternehmen selbst im Monatstakt Applikationen nach Beliebtheit und Funktionalität aus und vergütet ihre Entwickler mit Prämien bis zu 20.000 US-Dollar. Mittlerweile haben sich auf Grund dieses Anreizes über 250 Apps in den von Blockstack betriebenen AppStore app.co aufnehmen lassen und werden aktiv entwickelt. Ausgezahlt werden die Prämien in Form der Blockstack-eigenen Kryptowährung Stacks (STX).

Was zunächst nach einem Gag aus der Marketing-Abteilung klingt, ist das Resultat eines 2018 erfolgreich durchgeführten Token Sales, der langfristig Blockstacks Entwicklung finanzieren soll. Das Unternehmen veröffentlicht derzeit weitergehende Tools, darunter auch die LISP-ähnliche (und aus besonderen Gründen nicht Turing-vollständige) Smart Contract-Sprache Clarity, mit der sich “echte” Smart Contracts auf der STX-Blockchain realisieren lassen.

Synopsis & TL;DR

Bitcoin ist derzeit gemessen an seiner Akzeptanz das nachweislich am besten funktionierende dezentrale Währungssystem, das keinerlei Kontrolle durch externe Parteien unterliegt. Dabei sind natürlich auch die systemischen Schwächen der Ledger-Technologie im Falle Bitcoin am sichtbarsten: Fragen zur Skalierbarkeit, Nutzbarkeit und hohen Transaktionsgebühren werden von Sekundärtechnologien bereits adressiert, sind aber noch längst nicht abschließend beantwortet.

Den durch intensiven, aber zum größten Teil überflüssigen Mining-Aufwand erzeugten Vorteil, ein nicht kompromittierbares System des Vertrauens zu sein, erkauft sich Bitcoin mit einem untolerierbaren ökologischen Fußabdruck, der sich nur durch Level-2-Technologien oder alternative Konsensverfahren auf ein erträgliches Maß reduzieren lässt.

Davon abgesehen ist Bitcoin ein verlässliches, weltweit funktionierendes Protokoll zum Austausch von Werten und zur Absicherung von Vertrauen — ein nicht zu unterschätzendes erstes Werkzeug auf dem Weg in eine dezentrale Zukunft, in der jeder mit jedem über alle Grenzen hinweg sichere Geschäfte abschließen und Verträge eingehen kann, ohne von Währungen, Regularien, Zöllen oder korrupten Institutionen eingeschränkt zu werden.

Das Bitcoin-Prinzip was originally published in t14g on Medium, where people are continuing the conversation by highlighting and responding to this story.

Turbine Kreuzberg on Twitter

🔊12 talks with live code &amp; demos, 2 panel discussions, a #codingchallenge by @platformsh ,meet &amp; greet with @blockstack @jolocom and @twilio and a lunch buffet🍴 in the beer garden of @Festsaal are waiting for you at #devday19 on 🗓️ May 25th! https://t.co/Xpx9r1EuXK 🇩🇪🇵🇹

10. DEV DAY is about the art of coding and the every day life of developers, not dedicated to a certain topic

You for sure have attended conferences that focus on a certain technical field, technology or tech stack, for example “kubernetes” (Kubecon), “Golang” (GopherCon) or Google I/O. DEV DAY is different: we explicitly don’t focus on a certain area but instead we want to host a conference according to our 2019 motto “Coding & Beyond”. It doesn’t matter if you just jumped into the software development business or you are about to do so, whether you’re an experienced señor(a) developer or if you’re affiliated with programming in any other way, e.g. as scrum master, product owner, founder or agile coach: this is an event you want to attend for sure.

9. Devs of all trades form a crowd of inspiring people in a great location

DEV DAY’19 is not only dedicated to talks and presentations, it’s rather a one day platform event that we’re providing for anybody interested in coding. In practice that means that all talks are primarily given to inspire all attendees and discuss the concepts on site. The spaces that we chose to host DEV DAY will give everyone enough room to go beyond the talk and discuss aspects of it with speakers and attendees afterwards.

DEV DAY in Berlin is hosted in the spacious event area of Festsaal Kreuzberg which you might know from the last music gig you might have attended in Berlin. We have booked the large event space (not the music stage ;) ) on the western side of the building, have reserved a large room for our live video stream with Faro, kept one large room free for our coding challenge attendees and you can use the large beer garden area to get in touch with other people and discuss things without disturbing others.

In Faro the event will again be hosted by the local Turbine Kreuzberg subsidiary, which until then will have gained a lot of new space (be surprised where that’ll be ;) ). It comes with a large auditorium and a dedicated speaker’s stage, a whole basement area that hosts our coding challenge and the Berlin live stream, as well as a cozy street site for networking.

Besides the 12 talks we’re also hosting two panel discussions during the lunch break where we’re inviting all speakers, sponsors and even some very special guests to the stage to discuss two highly relevant developer topics and want to dig deeper into the “beyond” part of this year’s claim.

8. Feel the spirit of the Algarve, even when you are in Berlin

The idea of DEV DAY started back in 2016, when Turbine Kreuzberg’s Faro office hosted it for the first time. We’ve learnt a lot since then, e.g. about the preferred spirit we want to live and promote during our DEV DAYs. 2019 will be the second year that we’re hosting DEV DAY in Berlin and we want to give everybody the chance to take part in both conferences.

We therefore stream all the talks (and even the moderation) live on Youtube in a dedicated room and if you like, you can get in touch with the audiences and speakers at the other site with video chats in real time.

Here’s a preview how talks look like when they’re streamed:

7. We’ve got 12 great talks and they all “fight” for the Best Speaker Award

Lets face it: every speaker at a conference has already taken away a grand prize! Taking the stage earns you a lot of positive karma provided by your audience. You have 30 minutes to illustrate your ideas, to show what you love most, to push your ideas into the minds of more than 100 people hanging on your lips.

But out of a DEV DAY tradition we’re taking this one step further and print a memorable “Best Speaker Award” on site with our 3D printers. After the last stage has been taken and the virtual curtain has fallen, our audience will vote for the “best speaker” they experienced that day. If everything runs good, she can take home the freshly printed trophy right away.

2019’s talk topics include

directly craft related topics

• frontend development 2020: what’s on your stack?
• UX is kind. UX is smart. UX is emotion
• Tick Tock. What the Heck is Time-Series data?
• Unity Audio — making the best of what it’s got
• Writing compilers in Javascript using ANTLR

upcoming technologies

• How machine learning is used in processing text (ML)
• Current trends in NLP for finance (ML/NLP)
• Things can talk in our office (IoT)
• Adding Decentralized IDs and User-Owned Storage to a React App (Blockchain / DLT)

“soft” topics / how to improve your coder’s life

• Egoless Programming
• How to promote the culture of learning
• Do you have a minute? Why a CPU does not bother you but you maybe should

You can find the complete talk agenda including all the speakers’ profiles on our agenda page.

And did we say that we printed extraordinarily rememberable name tags exclusively for our speakers?

Stefan Judis on Twitter

Just received my badge for @turbinekreuzbrg's devday in a few weeks and it's a save icon. 👌👌👌 Now, I only have to remember to bring it with me. 🙈

6. Nonsense, recruiters and bad manners stay outside

Some talks you might have attended at other conferences have been solely given to promote a certain kind of product. While every speaker will have her own catch on the decision between “advertisement” and “show an amazing piece of technology”, we told all our speakers to concentrate on the practical parts. So every (tech related) talk will come either with at least 1 line of code or dedicated demos that illustrate what has been said.

That also holds true for what our sponsors will contribute to the whole thing: Twilio (the company behind Sendgrid, if you know that one better) will demonstrate their cross-channel messaging stack that enables complex message driven usage scenarios. Blockstack shows off their amazing decentralized application building toolchain, related services and its app mining program that allows you to earn money by writing useful apps. Finally, Jolocom will be there to answer all questions on how you can use their implementation of the uprising self sovereign identity technology to identify and interact with user profiles without sharing all the users’ details — a game changing technology that might affect all our lives in the future.

Naturally, we’d like to encourage everybody to join us at DEV DAY, regardless of any diversity issues that might apply to them. We are committed to providing a friendly, safe and welcoming environment for all, regardless of gender, sexual orientation, ability, ethnicity, socioeconomic status and religion (or lack thereof). By attending DEV DAY every participant implicitly agrees to our Code of Conduct and everybody will be aware of the consequences when not obeying its rules. Nobody should have to be concerned about harassment or bad behaviour at any time. It’s very sad that these — actually obvious — rules of human interaction have to be mentioned in such a long paragraph, but we’re very well aware that this still might be an issue.

5. Batteries included + a special childcare offering

Thanks to all our sponsors we’ve got a little more financial freedom in terms of food options and amenities, so be prepared for healthy and tasty choices on the DEV DAY lunch menu! We’ll also serve pretzels, croissants and coffee as strong as Batman in the morning. And of course all (soft) drinks are on us as well.

In case your offspring holds you back from joining DEV DAY, we have negotiated a special offer with a dedicated child care service in Berlin. Since we’re not as large as e.g. jsconf.eu (but we’re coming!!) we unfortunately cannot afford onsite child care yet, but feel free to checkout the private offer discount and all details for individual child care that day here.

Daniel Fahlke on Twitter

Childcare at conferences and events. Would you make use of it, when it is available?

4. Our sponsors are 100% dedicated to software development and its community

Twilio, Jolocom, Blockstack and platform.sh are all dedicated companies offering services and applications to make the life of developers easier and more delightful. They support local communities with event sponsoring, they contribute to open source projects and they support local meetup hosts as much as they can. We think they’re the perfect backup for a developer centric conference that DEV DAY always wanted to be.

As the main sponsor, initiator and company behind DEV DAY, we’re proud to announce Turbine Kreuzberg as our very special event partner. You might have guessed that most of the organizational effort we’re undertaking for DEV DAY has been paid by them. But DEV DAY is far more than a “Turbine” event: as a technical agency that builds b2b commerce solutions and enterprise marketplaces for a living, Turbine always strives to learn about new technologies and find inspiring people willing to push the boundaries of their tech stack.

Turbine Kreuzberg wants to establish a “playground”, a room for digital innovation to leverage the ideas of communities together with their members. Turbine therefore invests in technical events and local meetup groups (e.g. the newly founded “coding earth” association that currently powers meetups in Germany and Portugal).

3. We’re supporting open source projects & we mean it.

Before putting them on our website, we asked many developers which open source projects they would love to have supported. And they really came up with many of them. After a voting session with around 30 people, we decided to support these three (+1) very well known initiatives officially with DEV DAY’19. If you want to join us in supporting them, you can do so by adding an arbitrary amount to your DEV DAY ticket.

FreeSoftware Foundation

Your support makes the Free Software Foundation’s work possible. Will you power up the free software movement with a donation today? We use these funds to help us defend the freedoms and rights of all computer users, to nurture the GNU Project, to certify freedom-respecting electronics, and to battle the practice of Digital Restrictions Management.

OpenStreetMap

OpenStreetMap is the largest open geographic database in the world, the data infrastructure for multitudes of mapping projects around the globe. Your donation to the OpenStreetMap Foundation will cover our core operational expenses in supporting the OpenStreetMap project: hardware costs, legal fees, administrative assistant and other expenses of our working groups and administration.

NumFocus

NumFOCUS envisions an inclusive scientific and research community that utilizes actively supported open source software to make impactful discoveries for a better world. Your donation helps bring this vision to life!

and, more likely known to our Faro attendees:

Faro Open Source / Milage+

The University of Algarve developed the MILAGE LEARN+ app in the course of an ERASMUS + project to foster mobile learning and motivate students to innovative pedagogical learning models more appropriate to the needs of today’s students. Its pedagogical model includes gamification to motivate students, self-assessment and peer evaluation to promote autonomy and different learning styles and ensure that all students have access to a quality common knowledge.

2. An all day Coding Challenge: You asked for it, you get it!

If you attended DEV DAY 2018, you might have checked out the coding challenge that we ran during the day. It has been mainly built around some algorithmic puzzles we chose on hackerrank and we heard that some of you really liked the idea. For 2019 we came up with something even greater.

Thanks to our partnership with platform.sh we’re presenting you a unique chance to collaborate on something bigger: let’s build a website dedicated to developer news and interesting artifacts — together, using platform.sh’s unique language agnostic PaaS tooling.

Ahead of DEV DAY, we’re setting up the website’s scaffold and git repos and it’s up to you to fill the site with life. Choose from Go, Node.js, Python, Ruby or even PHP to write micro services which contribute to a collaboratively built website and run dedicated micro applications on the platform.sh monorepo stack. It’s totally up to you what kind of service widget you build, but here are some ideas for your inspiration:

• display all meetups within a certain radius
• show an event calendar for developer events
• seek “#php vs #golang”, “#react vs #vuejs”, “#blockchain vs #hashgraph“ on Twitter and display a dashboard of total tweet counts
• parse news sites to show the latest developer related news
• fetch images with hashtag #devday19 on Instagram / the daily xkcd and rotate them in your widget

All participants of our coding challenge will take home some very memorable and living(!) item that stands out of all takeaway goodies you might get that day.

1. You’ll leave the location with a smile on your face

The feedback we received last year was really nice. Since DEV DAY is still quite a small conference for like minded people, the networking ratio and the amount of personal talks and get-togethers is so high that it feels more like a class reunion than a real conference. You’ll have the chance to get in touch with sponsors and speakers directly, you can contribute ideas during the event, find new friends or colleagues to (maybe!) found your next company — and of course you won’t go home with your very own DEV DAY’19 t-shirt.

Here are some quotes we heard last year:

It was one of the best conferences I’ve ever been to. The idea of the challenge was really great :+1:

Thank you guys for organizing this awesome event for the algarve community. You guys rock.

You guys are amazing! From what I see as a visitor of your event I was really impressed. This is a great event and gives this for free to the community makes me want to say thank you to each of one of you at Turbine and make me want to work with you guys! I think in this area creativity and people are the best asset you can have and you are the kind of company that validates that and I am happy to see that. I will send also an email just to say thank you and maybe in future, we can do something together.

Wrapup / tl;dr / pricing

Considering the amount of content DEV DAY’19 has in charge for you, we think that €20 (reduced offering for students are €8) are a ridiculously low admission fee for a conference. If you still are unsure if you want to spend them, ask me for a special promotion code and give me a good creative reason to provide one for you (e.g. “I’m freelancer on Wordpress and my customer doesn’t pay on time” or “I can’t find a job because everyone considers me overqualified” or “I invest all my money into a revolutionary new CO2 sucking device that’ll save planet earth”).

Here are the perks in short. By attending DEV DAY’19 you get:

• 12 talks
• 2 panel discussions
• free breakfast, lunch & beverages
• a coding challenge you can use to prove your collaborative coding skills
• a chance to meet up with up to 250 likeminded coders and make new friends
• a super nice DEV DAY’19 t-shirt
• a chance to meet me in person :)
• a good time killer for your lazy Saturday with huge opportunities to learn something new for a ridiculously low price tag.

That’s all, folks, now get your ticket for Berlin:

DEV DAY 2019 BERLIN

or Faro:

DEV DAY 2019 FARO (PT)