EsoChain — Distributed Rituals

Eldritch problems require modern solutions.

How the technology that gave rise to Bitcoin could help the more satanic inclined among us.

An artist’s rendition of how our product would be implemented.

Last December I was at a friend’s house for a reunion and, between a sip of wine and a bite of lasagna, I noticed that one of my pals was strangely silent, barely eating. Later that night I approached him and tried to get him to open up. After a couple of drinks he finally spilled the beans, and it turns out, to my dismay, that he was mourning.

Just a couple of days before a friend of his apparently passed during a failed invocation they had at his cult, as the demon being called emerged angered by their ritual and consumed the first soul he found. I, of course, was flabbergasted. How am I supposed to believe, in 2019, that a cult worth this name can fumble a simple invocation? Did they not speak the power words? Did they not light the braziers with olive and sycamore branches? Did they not draw the pentacle with the sacred sword? My disbelief kept growing as I realized that, among the many practices that were impacted by tech revolution, such as dating, shopping, chatting, esotericism has not been impacted, how could this be? I promised him such a thing would not happen again.

Luck would have that I happen to work at an IT company, and I also happen to be quite the occult nerd, and so, after months of research, testing, studying and theorization I’m glad to present EsoChain, the blockchain to ease the troubles in everyone’s rituals.

What’s a Blockchain

If you’re already up to speed, you can skip this part

Although still a contested term, all can agree that the first example (for some the only) example of blockchain is the one underlying Bitcoin. In general terms, a blockchain is a distributed ledger that doesn’t allow modification of values or forgery of new messages and that has a consensus algorithm that has to validate every message (or transaction). Some blockchains also implement so-called smart-contracts, distributed applications that leverage the already existing network to have their operation verified by the peers.

The three elements that define a blockchain are:

Peer-To-Peer Network

As the name would imply, a peer-to-peer network is a network in which messages are exchanged directly between the participants and there’s no central server to handle all the traffic(although they can have some hierarchy of nodes). Some examples of peer-to-peer networks are BitTorrent, a widely used file sharing protocol, Tor, an anonymous routing protocol used to navigate the “darkweb”, or going back a bit, Usenet and IRC, in some of its components. Some commercial applications, like for instance the gaming platform Steam, use a peer-to-peer scheme to relieve the main servers of some of the load during download operations.

A typical peer-to-peer network. Note that not all nodes must be equal.

Signature Algorithm

The two main operations that are needed to ensure a good functioning of a blockchain network are hashing and the digital signature.

Hashing is the action of running some data through a cryptographic hash function, a function (an operation) that takes in said data and provides a fixed-length output, such that it’s almost impossible to connect back said output to the input data. Hashing can be used to verify the validity of data, since hashing the same input always produces the same output and it’s a very fast process to do.

A digital signature is a crypthographic scheme used to verify that the sender of a piece of data is indeed who he says he is and that the data has not been altered since the signing. Such scheme leverages asymmetric cryptography, or public key cryptography, to allow every member to have one private key with which he signs the messages and one public key that everyone else can use to verify that the message was signed by the owner of the private key (which is assumed to be him). A commonly used algorithm is ECDSA, Elliptic Curve Digital Signature Algorithm.

To decipher the meaning of an encrypted message, one must know the secret.

Consensus and Ordering

Data transmitted on a blockchain has to be valid and ordered beyond the simple identity and integrity checks that we explored in the previous point. To guarantee such validity a consensus algorithm must be established between peers, that allows the network to work even if some of the peers are not following said algorithm.

First of all a transaction must be considered valid by the peers that receive it. This can mean different things based on the network we are looking at, for example, in Bitcoin, a transaction won’t be valid if it doesn’t spend the output(remainder) of a previous transaction or if it spends more than it has available.

Transactions are grouped in blocks, which are then linked to eachother.

The transaction must then be communicated to all peers within the network to keep their ledger up to date. This can be a problem, since some transaction may need to be registered in a specific order, and some peers may be very poorly connected and get transactions in the wrong order. The solution, that also gives the name to the technology, is to group transaction in blocks and propagate such blocks through the network. Blocks are enumerated and each block contains the hash of the previous one, so as to preserve ordering. Since multiple peers may produce different blocks, depending on what transactions they receive, and such blocks may be conflicting, we find ourselves in need of a consensus algorithm.

In general a consensus algorithm by which peers on the network agree upon which will be the next block (or the next network status). As before, this can take different forms depending on the network needs.

Proof-of-Work (PoW) is the chosen consensus algorithm of Bitcoin, selecting the first block that has attached the solution to a particularly hard mathematical puzzle (based on hashing, as seen before, so very easy to confirm), and if multiple blocks conflict on this too, give reason to the block with the higher block number (the total count of blocks up to this one). In such a way we guarantee that the network, if not consistent instant by instant, will eventually be consistent.

The other honorable mention is Proof-of-Stake (PoS), that gives reason to a block based on the total amount of a certain value (such as a cryptocurrency) held by the emitting peer.

An example of a Byzantine Fault Tolerance consensus algorithm. One of the nodes does not agree with the network status, but this does not stop the network from functioning.

Smart Contracts

Beginning with Bitcoin and later expanded and improved with Ethereum, some blockchains have implemented so-called “smart contracts” to execute and check code on the network itself. This has the advantage of verifying, through the already existing verification and consensus, that the result of the execution of some code is indeed the one declared and also the advantage of updating the ledger directly through said code. Many applications have already been explored using smart contracts, such as distributed voting.

The Problem: Pitfalls with Rituals

The invoker messed up during the ritual, and now a demon will haunt his dreams forever. How displeasing!

Coming back to the problem at hand, we need to analyze what aspects of old esoteric tradition could be improved with the introduction of blockchain technology.

First of all, let’s look at the classic scheme of how a ritual is performed in time.

As an invocation begins, the target demon is alerted of such event and begins waiting for the right steps to be performed. After such steps, the demon then manifests itself on the material plane to do his summoners bidding. If, however, something has gone awry during the ritual phase the demon might choose to manifest itself to mess with or even worse injure, either spiritually, mentally or physically, the invokers.

So what are, specifically, the problems that we can identify?

Bar some exceptions, the number of deaths grows about at the same pace of human population.

The first one that I’m sure pops to mind is the problem with correctly performing a rite after starting it. Be it from choosing wrong or false scriptures (22%, according to The Vatican Center for Exorcism and Esoteric Studies), poorly performed rites (39%), badly sourced magic components(15%), wrong astral season (18%) or hidden religious motives of one of the acolytes (6%), failed rituals account for more than 30% of all executed rites.

This percentage keeps going up each year (especially after the spread of internet), and it seems that extraplanar entities are not happy about this. More and more failed rituals (24%) end with at least one casualty, with a whopping (3%) number ending with all the involved deceased, vanished or possessed for life. This brings the yearly death toll (including bodies deprived of a soul) to almost 90.000 people, numbers rivaling with some of the worst humanitarian crises, an appalling tragedy!

The average DRS keeps increasing, and has already reached intolerable levels.

One that might not come so easily to mind is the continuing rise in Spiritual Response Time (SRT) as the years go by. With current population trends (7.5 billion people inhabit our planet at the time of writing), the continual fall of traditional religions in developed nations, and the relative stagnation of demonic population (an increase of only 6 million beings in the last 5000 thousand years), it seems obvious that SRT is bound to increase.

An all too common problem for the modern day practitioner.

In 1929 Fulcanelli estimated that the mean SRT was around 3 minutes, the average time for the final part of an invocation. Nowadays that number, always according to the Vatican, has skyrocketed to almost half an hour, prompting many cultists to repeat two or even three times the same rite to not loose Spiritual Queue Priority (SQP), increasing the chance of accidents and mistakes in the process. This also an impact on the cosmic well being of astral entities, since the more popular ones cannot answer most of the requests they receive due to immensely long Spiritual Queues (let’s just think about poor Baphomet, who’s SRT last year peaked at a whopping 64 days!)

Last but not least, it’s the growing concern among practitioners of the dark arts is the always increasing ability of religious agencies, such as the aforementioned The Vatican Center for Exorcism and Esoteric Studies (VCEES for short), to easily tap into the astral projection layer and trace back the summoned demons before they can do what they must. Although no official statistics exist about such phenomena, who doesn’t know someone who’s ritual has been interrupted by an exorcist breach in nowadays?

How EsoChain Works to Help Cultists

The proposed logo for EsoChain

EsoChain proposes to insert a blockchain layer between the execution of the ritual and the communication with the other realms, so that the ritual can be verified before being sent, protecting invokers from sending a wrongly executed ritual, freeing queue time for demons and at the same time encrypting and anonymizing the identity of the invokers.

Nodes

We firstly propose two kinds of nodes to be used in the network:

- The Cultist Node, used by human magicians.

- The Demonic Node, distributed to the otherworldly entities.

Both nodes can generate new blocks, but only the Demonic Nodes can create instances of smart-contracts on EsoChain, that we’ll call Smart-Rites from now on, and only they can decipher the identities of the cultist nodes that request their presence. By counter, only Cultist Nodes take part in the Proof-Of-Sacrifice and need to spend an EsoToken to execute rites.

The process for generating a key pair for the Cultist Node is a standard ECDSA procedure, while for the Demonic Node we suggest a novel way of identity verification, specified later.

Smart-Rites

Smart-Rites are, like every other identity on EsoChain, associated with an address, but they are not owned by anyone. They can be created only by Demonic Nodes. The identity verification is described in the Proof-Of-Sacrifice section. When the identity of a demon has been verified, the contract instance will be created in the ledger storage, and will be later executed through the EsVM (Esoteric Virtual Machine, a semi analogue of the Ethereum Virtual Machine).

A demon discussing his idea for an ICO to tokenize sinners souls with a developer.

A Smart-Rite has to have as input all the operations needed for a specific ritual, sent and verified as described later, and the public key of the demon-owner of the Rite itself. If the contract gets correctly executed, it will launch a confirmation transaction to the network, for the Demonic Node to listen.

Rite Proposal and Verification through Oracles

A Rite Proposal is a packet containing the address of the Smart-Rite to be invoked, the options to be passed to the Rite, and Oracle Message, used to verify the correct execution of the ritual. The identity of the sender is encrypted with the public key of the associated demon. The proposal will have to come from an identity having at least one EsoToken, that will be taken as “payment” for the rite and burned.

In Blockchain terms an oracle is a data entry point that allows for off-chain data to be inserted into the chain, for example an IoT thermometer could be used to upload data relative to the temperature of an industrial fridge to the network.

In our case we propose the use of a real life oracle, such as Delphi model, properly outfitted with a USB connector, to upload visual, auditory and enchantment data directly into the chain, in the form of an Oracle message. Such Oracle message will be included in the rite proposal packet to be later verified by another oracle, that will relive the experience of the uploader oracle and approve the ritual.

The beta of our oracle proposal.

Note that the demonic entity doesn’t have to take part in the verification process, even though they can, since most astral entities can emulate the functionality of an human oracle. The ritual, its options and its execution are verified by common peers of the network, thus relieving the demon of the need to verify each ritual manually.

Demonic Response and Invocation

When a Demonic Node sees an approved Rite Proposal get written on the chain the demon will verify it has read it by sending its private key (don’t worry about it, we’ll see later how this is ok) to the contract along with the original Ritual Proposal, the so called Demonic Response, and will use the same key to decrypt the real identity of the cultist doing the ritual. Once it has done that and the contract verifies the identity (see Proof-Of-Sacrifice down below), the ritual is complete and the demon can manifest itself.

An user enjoying the newfound time with his invocation.

Proof-Of-Sacrifice

The network needs to verify the true identity of a demon in two occasions:

When creating a Smart-Rite.

a Smart-Rite. When a demon communicates that he has approved the ritual

The private key of a demon will be set to the demon’s real name. Since a living being cannot read or hear the name without going mad, there’s no risk in giving this away at the time of the transaction being sent. Such key won’t be written on the chain for health concerns. (Note: Some people can’t handle the sight at the point that they die right instantly. In any case, we suggest putting down the subject anyway)

When one of the two transaction specified above is sent with the private key attached, Cultist Nodes will need to verify them.

To do so, they’ll have to provide an human vessel to read the key attached. If the key is a true one, the vessel will almost instantly loose his mind. At this point, through the help of the Oracle, they will communicate this event to the rest of the network.

Among the peers that have verified demons in the previous block, one will be picked just like a normal Proof Of Stake to build the next block.

Every peer that has participated in Proof Of Sacrifice will receive one EsoToken.

An oracle verifying the sacrifice and yielding the token, to be used in future rituals

Conclusions and future Developments

As we’ve seen, EsoChain manages to:

Lighten the burden of ritual verification previously bore only by the demons themselves.

the burden of ritual verification previously bore only by the demons themselves. Protect cultists from the effect of wrongly executed rituals, by avoiding demonic anger.

cultists from the effect of wrongly executed rituals, by avoiding demonic anger. Hide the identity of cultists performing rituals while still allowing demons to locate them.

Some obvious downfalls and points to improve are:

Scalability , as more rites get performed, more people have to be sacrificed.

, as more rites get performed, more people have to be sacrificed. Morality , as above, but probably can’t be fixed.

, as above, but probably can’t be fixed. Allow the invocation of angelic entities, since the protocol requires a sacrifice to go mad at the sight of the private key, an angelic entity won’t be able to be verified.

entities, since the protocol requires a sacrifice to go mad at the sight of the private key, an angelic entity won’t be able to be verified. Differentiate smart-rite cost by time required for oracle verification.

by time required for oracle verification. Non-locality of cultists, we are currently in the first steps of verifying if it is possible to not have all the cultists in the same location at the time of the ritual.

of cultists, we are currently in the first steps of verifying if it is possible to not have all the cultists in the same location at the time of the ritual. Usability of oracles, since the USB implant is quite laborious, we are already working with NeuraLink to provide a more streamlined process.

We’ll soon be publishing the github for this project, suggestions and comments are welcome.

By Edoardo Tommasi and Lorenzo Rossi, Banco Digitale di Firenze.