Every day, we are faced with a miscellany of claims and assertions made by various entities in the real world and on the web that we have to work with. Typically, we resort to the classic trust assumptions and relationships of the systems we operate in, such as an entity being honest, or an authority, to establish confirmation of such claims. Sign Protocol offers a suite of tools, infrastructure, and standards to create a unified future where all claims and assertions on the web and the world around us are driven by verifiable attestations on any blockchain.

We have posted numerous articles in the past weeks that outlined the high-level core concepts of Sign Protocol but starting from this moment, you get to experience it yourself first hand. Before you dive into sign.global, let’s go over some of our technical highlights.

Attest with No Size Limits

We have accumulated a great deal of valuable experience on building applications that utilize Arweave as a decentralised storage solution from the development of EthSign Next, and all of that has been iterated upon once more in the development of Sign Protocol.

For starters, Sign Protocol offers two data publishing modes:

• On-chain mode, which utilizes blockchains for the robust guarantees of their storage protocols, such as data availability and global consensus for history-keeping and state tracking. Sign Protocol will have support for EVM-based chains on launch, followed by integration with non-EVM chains, including Starknet, Solana, and TON. This mode publishes attestations via smart contracts which in so doing, make the attestations trivially composable with numerous other smart contracts on the same chain. It’s important to note that depending on the blockchain being utilized, the costs for publishing attestation data on-chain may be prohibitively high due to the scarcity and high demand for block space on that particular chain.
• Off-chain mode, which leverages data storage solutions for storing attestation data. Sign Protocol will be using the Arweave platform for this purpose. This mode is often cheaper than the on-chain mode, by up to 1000 times, as solutions like Arweave are purposely designed to offer abundant bandwidth provisions dedicated to data storage. Thus, they can offer significant cost savings to store a unit of data.

For our technical readers out there, you might be wondering how is it possible at all for attestations made on Arweave to be read by on-chain smart contracts. Well, keep reading…

Attest with No Platform Limits

In on-chain data publishing mode, Sign Protocol is designed to be a chain-agnostic protocol, just like EthSign Next. This means that Sign Protocol can be natively implemented and operated on just about any conventional blockchain system. Additionally, in off-chain data publishing mode, Sign Protocol has been designed to offer cross-platform extensibility via Arweave. This means that attestation data stored on Arweave can be accessed by users and services from any other platform, especially blockchain systems like Ethereum, Polygon, Zetachain, and many others.

Algorithm-agnostic Consent

In off-chain mode, Sign Protocol supports ANY form of consent generated by ANY algorithm, as long as they can be independently verified. Unlike Solidity which only supports secp256k1 ECDSA or other blockchains that only support EdDSA, Sign Protocol can easily add support for secp256r1 ECDSA (which is used in Android and iOS devices), RSA (which is used in many traditional web2 systems), and more. Aside from digital signatures, zero-knowledge proofs and TLS-MPC computations are also valid forms of consent that we work with. Whatever kind of proof that you have, whatever signing algorithm you use, whatever chain you’re natively on, we can get it done.

Verifiable Consent Bridging

Sign Protocol offers verifiable consent bridging that enables schemas and attestations to be freely bridged between all supported chains, including Arweave. For example, if you attested on Arweave but want to move your consent to other chains for the sake of smart contract interoperability, we can get it done. Actually, scratch that — we don’t get it done, YOU get it done! By adding support for independent witnesses, in the future there is no need to go through us to bridge your data at all.

Attest with No Gas Limits

We are here to augment your on-chain attestations with Arweave and off-chain datastore. If your attestation data size results in skyrocketing gas fees, simply offload it to Arweave or IPFS* with our help and store a lightweight CID instead. Sign Protocol schemas and attestations have built-in indicators that make it clear where data should be fetched from. If you are not a fan of decentralized storage or have data custody restrictions, we also support unchecked custom storage locations.

*IPFS storage cannot be considered permanent.

Attest with No Privacy Limits

We have brought over the work done on encryption in EthSign Next to Sign Protocol. That’s right — Sign Protocol makes use of EthSign Password Manager to make passwordless private attestations possible on public blockchains. Make the contents of your attestation visible to nobody but specified recipients with a single click, only at Sign Protocol.

The Sky is not the Limit

In on-chain mode, Sign Protocol gives schema builders the ability to add a hook contract which is called with every attestation and revocation made based on that schema. Hooks open the door to countless ways of extending the functionality of Sign Protocol. We gained a great deal of inspiration regarding hooks from their introduction and use in Uniswap V4.

In Conclusion

EthSign is proud to usher in a new era of Verifiable Trust for trust systems across the web and the world around us through attestations.

With the launch of Sign Protocol, we are excited to have you all explore and utilize it, and we can’t wait to see the effective attestations you’ll make, with no limits.

Sign Protocol: Attest with No Limits TODAY was originally published in Sign on Medium, where people are continuing the conversation by highlighting and responding to this story.

At EthSign, data privacy is one of our top priorities. Not only does selling user data have nothing to do with our business model, one of the major tenets of Web 3 is for users to have control over how their data is used and anything contrary is a betrayal of the entire space. In this article, let’s take a closer technical look at how EthSign honors those principles and handles user secrets.

Zero-Knowledge Encryption

ZK is one of the hottest topics in blockchain but it is important to note that when people mention ZK, they are usually referring to zero-knowledge proofs. We don’t currently utilize zero-knowledge proofs in our products but we do extensively utilize something of similar principle — zero-knowledge encryption.

Zero-knowledge encryption refers to the practice that prevents anyone aside from the sender and intended recipients from decrypting encrypted data, not even the service provider middleman. This is also known as end-to-end encryption (E2EE), which is a standard practice across major communication platforms such as Google Messages RCS, Signal, and Proton Mail. They all have different implementations of the same concept with varying degrees of transparency and user-friendliness. We wanted to maximize both while embracing the Web 3 ecosystem, therefore we came up with our own solution.

EthSign Keychain

Our newly launched EthSign Keychain is a MetaMask Snap that serves as a general-purpose password manager for all supported browsers, much like 1Password, LastPass, and BitWarden. Keychain gives users the option to synchronize their password records via our hosted service on AWS, the decentralized Arweave network, or offline manually through an exported JSON file. Going with either of the first two options means sensitive user data inevitably persists temporarily on our servers or permanently within the public domain for everyone to see, both of which require a reliable encryption solution.

EthSign Keychain utilizes symmetrical end-to-end encryption to safeguard user secrets. First, Keychain requests a deterministic entropy value derived from your secret recovery phrase via MetaMask. The entropy is salted to be Snap-specific and no other Snap can obtain the same entropy. Then, the user can optionally add a second layer of security by setting a password that further modifies the entropy value. We use the resulting entropy value as the symmetric AES-256-GCM encryption key to encrypt all username and password records.

Once encrypted, those records are bulletproof and safe to be uploaded anywhere. You can be rest assured that unless someone breaks AES-256 encryption or compromises your secret recovery phrase, it is impossible for anyone other than you to decrypt those records.

EthSign Password Manager

One of the biggest roadblocks to adoption facing the entire Web 3 industry is the lack of user-friendliness. The onboarding process is tedious with mutiple downloads and requires some level of understanding of cryptography. To be fair, this is the direct result of building a system entirely on cryptography and mathematics. It’s incredibly secure but near impossible for your average grandma to use.

Since we never want to see any user data in plaintext, we strongly recommend our users encrypt their data when using EthSign. Because we want this done in a decentralized and non-custodial fashion, we mandate users generate their own passwords. This presents a problem because we humans suck at memorizing things yet due to the multi-chain nature of EthSign, we cannot exclusively use Keychain to store passwords as it is only available as a MetaMask plugin and does not support other wallets yet. In this particular use case, we also wanted password-sharing capabilities so PDF contract recipients don’t need to know the password at all to decrypt and sign. To address all of the above, we developed EthSign Password Manager, a feature exclusive to the EthSign web app.

EthSign Password Manager uses asymmetric end-to-end encryption to achieve secure password storage and sharing. To give credit where credit is due, we took a lot of inspiration from Web3MQ and XMTP so you will notice the workflow is similar. Random bytes are first locally generated as the decryption private key. A random message is then locally generated and signed by the user. The digital signature is then hashed to 256 bits and used as the ECIES private key*. A public encryption key is then derived, signed, and sent to EthSign to enable password sharing capabilities. The random message is also sent to EthSign so users can regenerate their ECIES private key when they switch devices. Possession of the random message alone does not compromise the security of this system and EthSign keeps a copy of this random message to prevent users from losing access to their encrypted data forever.

*For incompatible wallets, a master password is used in place of a digital signature.

When sensitive data needs to be shared, it is encrypted to the recipient’s public encryption key which is stored with EthSign. When encrypted data needs to be decrypted, the user retrieves the random message from EthSign, signs it, and derives the private key locally to decrypt. Just like the encryption system used in Keychain, it is impossible for anyone other than you to decrypt data intended for you.

A Cryptographic Awakening

The slow but steady adoption of blockchain technology has started a subtle paradigm shift in the way we think about our data and identity. Building applications on blockchain-oriented systems means we must process data in a way so that secrets are not compromised when stored in public or available for anyone other than the intended recipient. The cryptographic-centric approach has quietly rippled into the Web 2 world in the form of Passkeys, which is a custodial wallet controlled by your service provider (Apple, Google, etc.) that replaces usernames and password pairs as your identity.

However, there is still a major difference between utilizing cryptography and being truly Web 3. What makes this even trickier is the constant need to optimize UX in a system based on something fundamentally user-unfriendly. It is a fine line between decentralization, security, and convenience, and EthSign will continue to walk this line with great care.

How EthSign Handles Your Secrets was originally published in Sign on Medium, where people are continuing the conversation by highlighting and responding to this story.

Built on Arweave, EthSign Next is our major pivot into the world outside EVM-compatible blockchains. Our new architecture allows not only users from different blockchain systems, but really anyone that possesses a cryptographic keypair to digitally sign, encrypt, and permanently store documents and independently verify their validity. The user interface has received another facelift and numerous quality of life features have been added based on feedback from EthSign 4. Now, Alice from Bitcoin can seamlessly sign documents with Bob from Ethereum, Caine from TON, and Sam from Solana.

Every time we build a new iteration of our product, we take our user feedback and mistakes from the previous version to heart. EthSign Next is the culmination of more than a year’s worth of lessons learned and brings about an overhaul of the entire tech stack. It is our fastest, furthest reaching, and most usable EthSign product yet — and we think you’re gonna love it.

Breaking the Chain Barrier

From its inception, one of the biggest problems facing the entire Web3 industry is the fragmentation and siloing of different blockchain systems. Even for veteran users, switching between blockchains is an annoying process, not to mention blockchains built on different virtual machines require different wallets to access. On top of that, universal data interoperability is nonexistent between blockchains.

Therefore, in order to break the chain barrier, we must end the reliance on smart contracts. This is not to say things are any less decentralized — as explained previously in EthSign Next: Visions of a Unified Web, we keep decentralization by flipping the data verification workflow and performing lazy verification. As a result of this paradigm shift, we now support multiple wallets from multiple blockchains interacting with each other on EthSign. Signing a cross-chain agreement between Bitcoin, EVM, TON, and Solana users is becoming a reality.

Convenience that Matters

EthSign Next comes with a host of convenience features designed to make user interaction more intuitive and effortless than ever before.

Push Notifications

If you are a signer of a contract and the uploader has provided EthSign Next with your email address or Telegram handle, real-time push notifications will be sent out through emails or Telegram messages.

Signature Styles and Contact Book

Create your own signature style in Settings to customize the visual style of your signature. You can type, draw, or upload an image, and quickly access it in the future.

It’s difficult to memorize everyone’s address, even your closest co-workers and friends. EthSign Next allows you to save the contact information of your collaborators so you can invite them by name to future contracts.

Contract Management

It gets increasingly impossible to manage all the documents and signatures when you start to have hundreds or thousands of them. EthSign Next allows you to create an organized folder structure for easy contract retrieval and signature management.

Security that Counts

We never store any user information or telemetry unless it is absolutely necessary for the application to function properly. Email addresses and Telegram handles, for example, do not persist server-side and are automatically discarded once the notifications are sent out. Your document and signing data never leave your browser unencrypted unless you explicitly consent to bypass our industry-standard AES-256-GCM and ECIES encryption.

We take privacy and data security extremely seriously — our business model does not and will never involve selling any raw or derived user data.

Blazing Fast, Zero Delays

One of the major complaints of EthSign 4 was the speed (or lack thereof) of the interactions and the fact that random errors caused by faulty RPCs would stop users from completing their task. This is not only frustrating for the users but for us as well, since these errors are caused by factors outside our control. By embracing the aforementioned verification model, we have moved away from smart contracts and replaced it with an open-source backend on AWS, resulting in the total elimination of any wallet errors and extra wait time. Taking complete technical ownership and control of the entire workflow also eliminates our inability to fix certain errors. Combined with front-end optimizations, CDNs, and edge servers, EthSign Next is our most performant product to date.

Decentralized and Trustless

Inarguably, two of the most important questions in the industry are “wen token” and “how centralized is this product”. With our previous talk regarding the use of AWS, it is only reasonable to raise some questions on our engineering practice in EthSign Next. Have we finally taken the red pill and gone down the rabbit hole of centralization since some think ordinary users don’t know any better or actually care?

For the longest time, we have struggled with striking the right balance between decentralization and usability. A product cannot be so decentralized that we become a hostage to the various tech stacks we utilize that are completely out of our control, but it also cannot be so centralized that if the platform unexpectedly terminates service, all historical user data is lost or obfuscated.

In EthSign Next, we decided to adopt the practice of decentralized settlement. Any documents still being signed are stored centrally to improve user experience while those that have completed the signing process (aka that have settled) are automatically submitted to Arweave at no cost to the user. Of course, regardless of the storage location, we fully respect and enforce the encryption rules set by the user. If the document is encrypted, nobody outside the intended group of recipients can decrypt the document, not even us.

We also took steps to make sure our users can still access their signed documents and cryptographic proof-of-consent even if we are gone. Once your documents have been permanently stored on Arweave, you no longer need us to access them and their respective metadata. You can easily index, decrypt, parse, and verify all your completed documents via an open-source tool that we will release later this year.

Don’t trust us — trust the code.

The Fight is Never Over

EthSign Next is now live. It is our biggest and most daring upgrade to our core product ever since our inception and represents an ongoing paradigm shift within our team. Over the next weeks and months, we are committed to bring more features and optimizations to EthSign Next that will cement its place as the leading Web3 chain-agnostic digital consent protocol. In addition, the enterprise-focused EthSign Pro is also in the works and to be announced in the near future.

We once again would like to show our appreciation for our investors and community for staying with us through thick and thin. Without your continued support, we wouldn’t have made it half as far. From the entire EthSign Team, thank you.

EthSign Next: A New Era of Web3 Signing is Now Live was originally published in Sign on Medium, where people are continuing the conversation by highlighting and responding to this story.

With major players such as Bitcoin and Ethereum leading the charge, there is no doubt that blockchain has revolutionized the way we conduct transactions and manage digital assets since its birth in 2009. However, despite its growing significance and adoption, one critical issue remains: the lack of interoperability among different blockchain systems. This fragmentation has hindered blockchain technology’s potential to reach its full capacity and establish a truly interconnected digital economy.

At EthSign, we have always strived to provide products that would cover the maximum number of networks and thus reach as many users as possible. After multiple product iterations of attempting different approaches, we believe we have finally formulated a viable solution that ties together the fragmented ecosystem without compromising decentralization. Here is our journey — our past flaws, present aspirations, and future visions.

Early Lessons

In the 3.0 release, we tried to cover all our bases by deploying the smart contract onto more than 5 EVM chains as well as integrating Web3Auth, a wallet solution that allows Web 2 users to be easily onboarded through email or social logins. It sounds great on the surface until you realize we haven’t exactly covered all our bases and everything is still very much segregated.

To start, users must be on the intended network. If a user is on the wrong network, then the wrong data would be displayed. Any action performed on the wrong network, such as creating a document, results in none of the signers having anything show up on their dashboard. If Alice is on Ethereum and Bob is on Polygon, there is no way for them to sign documents with one another unless one of them moves over to the other network. This all makes sense technically but is incredibly counterintuitive in terms of UX. There were no shortage of panicking users reaching out asking why their documents disappeared, only to realize their wallet was on a different network.

In addition to the lack of interoperability, there are simply too many obstacles for users to overcome before they can do anything. Remember how we deployed the smart contract on more than 5 EVM chains? The question now becomes, which chain should the user use? This is a trivial question for blockchain veterans but a daunting question for newcomers who genuinely have no idea which chain to use. “Ether is the easiest to obtain but it costs more to transact on the Ethereum main network. Matic is more difficult to obtain, not to mention the fact that two versions of Matic exists (ERC20 vs. native), but gas fees are way cheaper on Polygon. Oh also, Ethereum main network is probably more secure than Polygon. By the way, we only covered two networks. There’s also Binance Chain, Avalanche, and Fantom, each with their own pros and cons.” With so much of an information dump, it’s incredibly easy to drive users away through analysis paralysis — when being presented with so many choices, users end up not choosing because they don’t know what to choose. This was especially problematic for Web 2 users who wanted to try our product through Web3Auth.

Mitigating the Problem

During our 3.0 postmortem, we decided to build 4.0 from scratch and adjust our strategy. Instead of supporting a variety of networks, we decided to stick with Polygon exclusively. On top of that, we would make use of meta transactions (thanks Biconomy :)) to pay gas fees for our users, eliminating the need to possess cryptocurrency entirely. This proved to be a great leap forward and skyrocketed our usage, gathering more than 180k signatures at the time of writing.

As our user base grew, familiar questions began to bubble up: What about other networks? What if I’m not on an EVM blockchain? What if I only have a Bitcoin wallet? Interoperability remains a major pain point, which we attempted to mitigate by forcing everyone to be on the same network and sponsoring all transaction costs — a rather hasty fix that fails to address anything fundamental. A more radical solution is needed to break the chain barrier and reach more users.

What’s Next?

After much consideration back on the drawing board, we decided to go big or go home. We set our sights on not only all EVM chains but also other blockchain networks such as Bitcoin, Solana, TON, and more. To achieve such a wide range of coverage across blockchains of massively varying degrees of programmability, we had to make some of the biggest changes to how our signing product worked on a foundational level. Up to this point, the core layer of EthSign operated in a rather simple manner:

When performing a write action (e.g. signing a PDF contract):

• Front-end parses user input and asks the user to sign it
• Front-end uploads parsed input and user’s digital signature to a decentralized storage platform (IPFS in 3.0, Arweave in 4.0) and retrieves the associated content identifier
• Front-end calls the appropriate smart contract function
• State is updated after the smart contract cryptographically verifies input parameters

When performing a read query (e.g. loading a signed PDF contract):

• Smart contract events are queried from The Graph
• Relevant state is reconstructed from queried data on the front-end
• State is rendered to the user

As you can observe, the current approach heavily relies on the smart contract to verify data integrity before permanently writing to state. Unfortunately, as crucial as the smart contract is, it’s also the single most significant roadblock to our vision. The fact is, smart contracts simply cannot cross from one chain to the next, plain and simple. We must deprecate its use to properly move forward. Here is what we propose:

When performing a write action (e.g. signing a PDF contract):

• Front-end parses user input and asks the user to sign it
• Front-end uploads parsed input and user’s digital signature to a decentralized storage platform
• State is updated

When performing a read query (e.g. loading a signed PDF contract):

• Storage payloads are queried from Arweave using tags
• Relevant state is reconstructed from queried data on the front-end
• State is cryptographically verified by the front-end
• State is rendered to the user if verification succeeds

You may notice there are much fewer steps when writing to state in the proposed approach compared to the current approach. Since we no longer use smart contracts, verification-related work is offloaded to the front-end when reading from state. This frees us from being tied to any single blockchain network and allows us to integrate any identity provider that supports arbitrary message signing and independent verification. The scope is now broader than ever since the concept of signing and verifying messages isn’t exclusive to Web 3. By shifting data verification computation to clients, we are able to support signing sessions that are cross-chain or even one that includes participants from both Web 2 and Web 3. This is an incredible advancement for us, a total paradigm shift in the way data is stored and processed. Instead of calling it 5.0, a brand new codename was born.

We are incredibly excited to announce the next step in the evolution of our signing product: EthSign Next.

A Unified Web

EthSign Next brings a host of new features with the most impactful and immediate being true cross-network support where users from completely different blockchain networks are able to collaborate with each other.

Here is the initial roster of networks we intend to support:

• Bitcoin
• Ethereum (EVM)
• Solana
• Aptos
• Telegram Open Network (TON)

Theoretically we can add support for any network, Web 3 and Web 2, as long as an identity system that supports private/public key based message signing and verification is available. An example of Web 3 and Web 2 interoperability on our platform would be a Bitcoin user initiating a signing session and inviting signers from Ethereum, TON, and Proton Mail (as it makes use of PGP keys).

Aside from the interoperability upgrade, we have also planned a complete UI facelift and a series of QoL improvements available in a future release later this year.

Roadmap

EthSign Next is currently under development and will be launching a closed beta soon. Eligibility is rolled out in tiers with SignPass holders having the highest priority, then Galxe NFT holders from our previous events, and eventually transitioning into an open beta. In addition, SignPass holders will have a direct line to the development and product team to help shape the future of this product.

Finally, I’d like to personally express my appreciation to our community and investors. We wouldn’t have made it this far without your unwavering support through all the ups and downs over the years. On behalf of the entire EthSign team, thank you.

Access EthSign Here
Twitter | Gitbook | Discord | YouTube

EthSign Next: Visions of a Unified Web was originally published in Sign on Medium, where people are continuing the conversation by highlighting and responding to this story.

A programming language is considered Turing complete if it is able to perform any general purpose computation. In order to be Turing complete, the system must be able to remember “states” of progress through computations.

In a computer program, the state is kept in-memory during runtime or in a non-volatile storage medium between runtimes for data persistence. DApps are also computer programs, they just have astronomically high execution and storage costs — some have estimated it costs $20k to store 500KB of data on the Ethereum blockchain. This number isn’t completely accurate but it gives the right idea. It is simply impractical to store any amount of data on blockchains such as Ethereum.

Yet, we must store data, sometimes in large amounts, to keep track of state. Since on-chain storage is too costly, we have to look for off-chain options.

Centralized Off-chain Storage

There are a few factors to consider when storing data off-chain, the first being whether we wish to use centralized storage.

Centralized storage isn’t bad. In fact, it is almost always cheaper, more familiar to work with, and more performant than its decentralized counterpart. The two main problems with it are the lack of transparency and concerns of data accessibility. To access data stored on centralized servers, the request usually goes through an endpoint. Anyone who has ever worked as a backend developer knows how trivial it is to modify the returned data for any given request. This entire process is also entirely opaque with the end user having absolutely no idea if the data returned is the data they are expecting. On the other hand, if the hosting site or owner decides to pull the plug, then all the data will perish and there is nothing anyone can do about it. These are both crucial aspects that most people in the NFT space tend to overlook — for example, BAYC NFT metadata is stored on their own servers and the server administrator can rug-pull anyone anytime by swapping out metadata or outright deleting them as they wish, but nobody ever talks about it.

Lastly, centralized storage is antithetical to the ethos of Web 3. It just seems a bit odd when a supposedly decentralized application keeps its state on a centralized platform.

Decentralized Off-chain Storage

When looking into decentralized off-chain storage solutions, there are a lot of options with the most popular ones being IPFS, Filecoin, and Arweave. They all have their pros and cons but some outweigh others. Let’s take a look!

IPFS is popular, but a bad idea

IPFS is often considered as the earliest and most widespread form of decentralized storage in the Web 3 world. Anyone can run an IPFS node of their own and start accepting data storage requests from users all around the globe. The network itself is completely free-of-charge and does not require registration of any kind to get started. Sounds real nice, right? However…

There is no free lunch.

When a file is uploaded to an IPFS node, it only exists on that node. There is no automated replication built into the protocol, meaning other nodes need to make a conscious decision to replicate a specific piece of data. Yet, when everything is done free-of-charge without any incentive aside from moral principle, why would anyone do such a thing? This isn’t a huge problem if your data is frequently accessed, as when routed through other nodes they actually store a copy as a form of caching. But for data not accessed frequently, IPFS functions just like a centralized storage repository.

Due to the fact that IPFS can be used without any form of authentication or payment, it has gained and maintained tremendous popularity, especially after the boom of NFTs in the past year or so. A quick YouTube search reveals almost all NFT tutorials utilize IPFS to store metadata. However, nobody ever asks what would happen if metadata files are lost when nodes containing the files go offline? Some would point to various IPFS pinning services, which provide data persistence at a monthly cost. But if we take a step back and look at pinning services such as Fleek* and Pinata, are they really that different from a Web 2 storage stack such as AWS S3? They actually run AWS servers behind the scenes and Fleek even provides an S3-compatible API, so what’s the point of using them at all? Just to abuse the IPFS branding and ethos?

*Fleek claims to also make use of Filecoin, but from personal experience nothing I have uploaded to Fleek has ever made its way into the Filecoin network

Filecoin has incentives, but isn’t permanent

The lack of incentive in IPFS is known all too well by its creator, Protocol Labs. Thus, Filecoin was born, an incentive network on top of IPFS. Filecoin introduces a storage market where miners on the network charge a fee in exchange for their storage space and retrieval bandwidth, known officially as making a storage deal. The problem with those fees is that they are recurring. If the creator of an NFT collection simply stops paying metadata storage fees, then their data will be purged. NFT owners are powerless and receive no forewarning in this situation.

Filecoin is also quite difficult to be directly utilized in a user-facing application. It works better as a backend middleware instead of being embedded in client-side frontend applications, which make up a significant portion of Web 3 projects.

Arweave works great, with caveats

Arweave is a decentralized file storage blockchain. In contrast, neither IPFS/Filecoin nor Sia Skynet (another popular storage platform) is a blockchain. As Arweave is a blockchain, all the properties of a blockchain directly carry over, including being tamper-resistant and transactions being permanent. Miners are financially incentivized to store a full copy of the entire blockweave (Arweave blockchain). Compared to IPFS, miners on Arweave are incentivized to replicate data. Compared to Filecoin, data storage only needs to be paid once and thus can be considered permanent. Accessing data on Arweave is also much faster than retrieving data directly from Filecoin which requires 1–5 hours to unseal, although Filecoin utilizes IPFS as its cache layer for quick access.

So everything looks good, what’s the catch? Well, Arweave isn’t without its problems.

• Uploading to Arweave requires payment in AR tokens, which is quite difficult to obtain as a US citizen.
• There’s the problem with Arweave being an actual blockchain. You see, one of the properties of blockchains is block time. For Bitcoin, it’s ~10 minutes. Ethereum, ~10 seconds. For Arweave, it’s ~2 minutes. This is entirely reasonable and actually quite aggressive when Arweave can have block sizes of up to 1GB, but it does prove to be problematic when it comes to user experience. If the user only wanted to upload a small amount of data, for example a 200KB PDF file, but has to wait for 2 minutes for a single confirmation, they would not want to use the product ever again.

Arweave is inarguably the closest thing to a usable permanent storage solution on Web 3, yet its UX issues bar it from mass adoption. But hey, I wouldn’t be writing any of this if I didn’t have a solution to present, right?

Bundlr.Network: Arweave’s L2

Enter Bundlr, a project that aims to push Arweave towards mass-adoption. They just launched their testnet in April 2022 as the founder saw all the issues mentioned above with Arweave and set out to address them.

• To address the first issue, Bundlr accepts payment in 14 different cryptocurrencies including ETH, MATIC, AVAX, BSC, and more.
• To solve the annoyance of waiting for block confirmations, Bundlr provides instant transaction finality on Arweave. In other words, uploaded data will be instantly available on the official Arweave gateway instead of having to wait for 2 minutes.
• As for the very last problem of exposing private keys, Bundlr actually does not require the user to even have an Arweave private key. It’s able to entirely abstract away anything related to Arweave client-side and utilize EVM/Solana/NEAR/Polkadot injected Web 3 providers for authentication and payment.

It’s not all sunshine and rainbows though, as Bundlr is still extremely early-stage and has some UX hurdles such as requiring users to go through multiple MetaMask popups before they can upload data and compatibility issues with Gnosis Safe, both of which are critical here at EthSign. In addition, we have utilized Biconomy meta-transactions throughout the application to sponsor gas fees for our users so they don’t need to own any cryptocurrency to use EthSign, removing a huge barrier of entry. Unfortunately, Bundlr does not yet support this feature and after a month-long trial run, we decided to look elsewhere.

Arseeding by everFinance: A robust Arweave light gateway

Arseeding is an end-to-end storage solution built on Arweave. Instead of being a frontend solution like Bundlr, Arseeding also provides an Arweave light gateway that we can run and host ourselves. Here are some of the reasons why we eventually decided to move to Arseeding:

• Arseeding’s gateway supports submitting payloads via HTTP endpoints, reducing dependencies and making the entire process magnitudes more flexible for us.
• We can pay the uploading fees for our users, thus only requiring a single signature from our users on their browser. There is now no need for users to deposit uploading fees and keep a balance separately, reducing complexity and the number of interactions.
• The gateway can bundle multiple uploads together into a single Arweave transaction to reduce fees.
• There is an API key system to restrict upload access to our gateway.

Arseeding is a very enticing solution because it offers us the possibility to make several UX improvements on top of its relative ease of use from a developer standpoint. It’s very easy to get up and running on an AWS EC2 instance and requires minimal maintenance. The implementation of Arseeding opens many possibilities for EthSign that we are excited to explore.

Conclusion

The quest for permanent data storage on Web 3 has proven arduous, yet not impossible. As the Arweave ecosystem further matures, I firmly believe that their practicality and efficiency will make them the first-choice decentralized storage solution across Web 3. The Arweave ecosystem is full of very talented and dedicated developers, so I’m excited to see the improvements they make to the L1 and L2 down the line. Until then, the quest continues.

Access EthSign Here
Twitter | Gitbook | Discord | Youtube

A Quest for Permanent Data Storage on Web 3 was originally published in Sign on Medium, where people are continuing the conversation by highlighting and responding to this story.

Renewed, Rebuilt

When EthSign 3.0 was initially conceived, our team only consisted of 5 members. We were still new to building a product from scratch and trying to find our product market fit. Although 3.0 is a usable product with over 10k signatures, it’s more of an experiment for us to find what works and what doesn’t. We have dabbled with different sorts of functionalities and continuously added new features as development went on. We will be the first ones to admit that EthSign 3.0 isn’t the most mature, nor the best designed, nor the most technically optimized product out there. However, in the process of developing and fixing 3.0, we gained invaluable insights that enabled us to narrow our product scope and work more efficiently.

As a result of lessons learned building and maintaining 3.0, the next version of EthSign is razor-sharp:

• Design-wise, we have identified various pain-points and extraneous features through our continued user interviews and UX research. The next evolution of EthSign comes with a redesigned user interface and a streamlined features list, making it simultaneously the most intuitive and powerful EthSign yet.
• EthSign 3.0’s tech stack is constrained by echoes of the past — namely EthSign 1.0 and 2.0. Because we kept building on top of legacy code, everything has gotten difficult to manage and maintain. This time, we are wiping the slate clean and starting from scratch. The smart contract rewrite is massively simplified and optimized, reducing gas used by 10x. Our frontend is now rebuilt from the ground up in TypeScript React keeping reusability, composability, and testing in mind from the beginning. Features are locked before development to ensure a coherent codebase. All of the above condenses into a faster development cycle and fewer bugs.

TLDR: The next version of EthSign is cleaner, faster, and more intuitive than ever.

Product Stability

While developing EthSign 3.0, we strived for maximum decentralization because we believed in the spirit of Web 3, which translated into a massively decentralized tech stack. However, this also meant our product became technically over-fragmented and any hiccups from any of our providers translated into a big impact on our end. To put bluntly, we decentralized too much. We have had numerous instances of our product partially ceasing to function or becoming inaccessible due to our providers having service interruptions yet unable to do anything about it because the infrastructure is largely out of our hands. While our efforts were idealistic, we must now act more realistically to guarantee the stability and usability of EthSign.

In the next version of EthSign, we will be taking back control of parts of our tech stack. For example, currently EthSign is statically hosted on IPFS. While this sounds quite good on paper, many of our users outside of North America have had issues maintaining a reliable connection with the site. Thus, in our next version, we will be looking into other alternative hosting and CDN solutions to improve accessibility. More changes to ensure product stability are coming to the new version but worry not, we are still very much decentralized in spirit.

The Game Has Changed

Through EthSign 3.0, we have gained a great deal of ordinary as well as institutional and DAO users. Leveraging EthSign’s core e-signing capabilities, we plan to roll out a suite of secondary products that accomplish previously off-chain tasks on the blockchain. The game has changed — a new era of on-chain smart agreements is upon us, powered by EthSign.

Access EthSign Here
Twitter | Gitbook | Discord | Youtube

A Sneak Peek Under the Hood was originally published in Sign on Medium, where people are continuing the conversation by highlighting and responding to this story.

Code and annotations: https://github.com/boyuanx/Solidity-Calls

EthSign on Twitter: "🚀Great going @arcxmoney 🤩We are announcing 10 EthSign ARCx Defi Passport Skin, skin holders will enjoy gas coverage of EthSign 3.0's services on Ethereum main nethttps://t.co/sdF83HRPTl pic.twitter.com/xvYDt6FGY1 / Twitter"

🚀Great going @arcxmoney 🤩We are announcing 10 EthSign ARCx Defi Passport Skin, skin holders will enjoy gas coverage of EthSign 3.0's services on Ethereum main nethttps://t.co/sdF83HRPTl pic.twitter.com/xvYDt6FGY1

The Problem

The simplest thing to do is to build ERC2771 compliance right into EthSign 3.0’s smart contract. Although it was deployed months ago, it is upgradeable and thus we have the power to alter its implementation. However, we would like to avoid this for multiple reasons:

• If the code is working well, then try to not modify it.
• It introduces tight coupling between components.
• We want the solution to be generic and modular.

The Plan

“All problems in computer science can be solved by another level of indirection.” — David Wheeler

The only way to make our solution truly plug-n-play without affecting the existing contract is to use a proxy. Proxies are nothing new — it is the underlying mechanism that enables upgradeable smart contracts. In essence, the proxy keeps track of the address of the underlying implementation contract and delegates the execution to the implementation while managing storage by itself. The use of delegatecall enables contract logic to be updated without affecting storage.

In our use case, we would like to build a proxy that only acts as a permissioned ERC2771 gateway that checks the user’s eligibility and if eligible, forwards the call to the implementation contract without costing the user any gas fees. Because we still want to use the underlying storage of the implementation contract, call will be used instead of delegatecall. We will have a dedicated article that explains in detail the difference between call, callcode, and delegatecall.

The proxy itself is extremely simple and straightforward. We will be making use of the fallback function and some ABI trickery to make it work with any smart contract. The fallback function is a special function that is called when the requested function signature cannot be found. It usually leads to a revert or STOP opcode but we can repurpose it to redirect the incoming call to our implementation contract.

The Execution

At this point, we really only need to accomplish 4 things:

• Write a proxy contract using call
• Enable ERC2771 compatibility
• Verify user permissions
• Finesse the ABI in JS

Writing a Permissioned Proxy

This part is very easy as we can make use of OpenZeppelin’s contract library. They provide a proxy preset that we can utilize right away:

import “@openzeppelin/contracts/proxy/Proxy.sol”;

abstract contract AbstractProxy is Proxy { ... }

First, we would need to implement two virtual functions:

function _implementation() internal view virtual returns (address);

function _beforeFallback() internal virtual {}

_implementation() is relatively straightforward as it simply returns the address of our implementation contract while _beforeFallback() is more interesting. As you can infer from the name, _beforeFallback() is called before the actual forwarding is executed and thus we can use it to determine if the function call should indeed be forwarded or not. We won’t cover what to write in this function since it completely differs from case to case, but here are a couple of ideas:

• Check if the sender holds a certain NFT
• Check if the sender is registered in a mapping

Then, we need to override and modify the following function:

function _delegate(address implementation) internal virtual { ... }

_delegate() is the function that handles the actual forwarding using Solidity assembly. You can view the same code with detailed comments in the GitHub repo but for the sake of formatting, I have stripped them from the snippets below.

By default it uses delegatecall:

assembly {
    calldatacopy(0, 0, calldatasize())
    let result := delegatecall(gas(), implementation, 0, calldatasize(), 0, 0)
    returndatacopy(0, 0, returndatasize())
    switch result
    case 0 {
        revert(0, returndatasize())
    }
    default {
        return(0, returndatasize())
    }
}

As we mentioned earlier, we want to use call instead. This only requires a one-line change:

let result := call(gas(), implementation, callvalue(), 0, calldatasize(), 0, 0)

Note that we now have an extra callvalue() in the passed arguments.

One important caveat that must be kept in mind: msg.sender will no longer point to the intended caller. Instead, it always points to the proxy contract. We will cover this dynamic in depth in a separate article. There are various ways of mitigating this issue, one of which is to make use of ecrecover(), but it would be nice to see the addition of a new type of call that forwards msg.sender as calling ecrecover() also consumes some gas.

Although the solution isn’t completely plug-n-play after all, the advantage is not having to modify any existing external interfaces. Instead, we can add ones that are intended to be called by an “operator” on behalf of the sender, much like how it’s done in various token contracts, such as permit() in DAI.

Enabling ERC2771 Compliance

Integrating ERC2771 is very easy with OpenZeppelin. We simply have to import, inherit from the relevant module, and call the parent constructor:

import “@openzeppelin/contracts/metatx/ERC2771Context.sol”;

abstract contract AbstractProxy is Proxy, ERC2771Context {

    constructor(address trustedForwarder) ERC2771Context(trustedForwarder) { ... }

}

ABI Trickery

While our proxy contract is now ready to go, there is a problem on the frontend. When we create an instance of a contract in web3.js or ethers.js, the framework reads from the ABI to determine the list of functions we are allowed to call. If we use the proxy ABI, we would only be allowed to call functions exposed in the proxy contract. But we want to call functions in the implementation contract and thus we should attach the implementation ABI to the proxy instance. This is completely okay because we implemented the fallback function and it properly forwards the call to the implementation contract, where the ABI will match.

Voila!

We now have created a permissioned proxy contract that enables us to pay gas fees for select users. The combination of ERC2771 and permissioned access certainly opens up a lot of possibilities as the underlying architecture of SignPass.

Next Steps

Very shortly we’ll be releasing a major batch of SignPass on BSC and Polygon, stay tuned for more updates! Early adopters, protocol partners, and investors of EthSign will be gifted with SignPass after this release, we thank you for your support along the way!

Access EthSign Here
Twitter | Gitbook | Discord | Youtube

Announcing SignPass: Permissioned Gas Sponsorship with Meta Transaction and Proxy was originally published in Sign on Medium, where people are continuing the conversation by highlighting and responding to this story.

Since the debut of EthSign 3.0 in June, we have merged over 120 pull requests and made over 300 commits on GitHub containing a plethora of bug fixes and new features as a part of our continued effort to boost performance, improve user experience, and introduce new features. Let’s dive right in to talk about some of the more noticeable ones!

New Contract Auto-Save

As much as it sounds like an excuse, the fact is, software bugs are inevitable — they are incredibly frustrating for both users and developers and EthSign is no different from any other piece of software. We have already patched a long list of bugs within the New Contract workflow but there are still a couple of stubborn and rare bugs that are difficult to consistently reproduce and would usually go away after a page refresh. Nothing is more infuriating when, as a user, losing all progress and filled information on a page refresh. To mitigate this issue as we continue to investigate these rare glitches, an auto-save feature has been implemented. Whenever the page is refreshed and you pick the same PDF file to upload, our code will detect if there was any previously interrupted progress and if so, will ask if you’d like to restore it.

Providing Feedback

We have made it easy and effortless to provide us feedback anytime you’d like. A dedicated and persistent Provide Feedback button has been added to all pages that leads to a Typeform popup where you can detail your experience and what you liked or didn’t like.

Parallel Loading, Error Handling, Pagination

We have overhauled the way contracts are loaded into the dashboard. Previously, we loaded contracts sequentially and chronologically. While it was more straightforward to code, the performance was severely throttled as there was only one contract loading at any given time. We now have switched to a parallel approach where all contracts are first represented as a skeleton placeholder and then loaded together in parallel. This required some modifications to our The Graph subgraph but the improvement was significant. We saw a 5–10x improvement in loading speeds and the reduced load times also meant the page is now less susceptible to network interruptions. The new method of loading also meant failing to load a single contract will no longer halt the loading of all other contracts. We have also added a Retry button for the ones that fail to load.

In addition, we were able to paginate the list of contracts instead of displaying it all on a single long list.

Contract Document Details

For our more technical users, you can now view more detailed information regarding your uploaded contract document.

Profile System

The profile system is arguably one of the most significant additions to EthSign that paves the way for numerous features in the future, such as push notifications and an advanced asymmetrical encryption option. For now, users can voluntarily associate an email address with their Ethereum account to receive push notifications regarding signing in the future. This information is stored securely in our auxiliary server and we will never use it for marketing purposes or sell it to advertisers.

One of the things we are proud of is our lack of reliance on centralized services. Although our auxiliary server is hosted in a centralized fashion, it will only ever be used for non-critical convenience features. In other words, if the auxiliary server ever goes offline, EthSign will continue to function normally and no major feature will be impacted in the slightest. This also circumvents the gas fee issues, especially on more congested networks such as the Ethereum mainnet.

Public Contract Verification

From the very beginning, we made it our goal to bring transparency to the document signing field — signed contracts and their history should be visible to everyone instantly at all times. We are now proud to introduce our public contract verification page. With the correct document key, signer address, and network combination, anyone is able to view the signature status of said signer and a complete history of the contract. The signature status can also be exported as a PDF for archival purposes.

The Road Ahead

As EthSign 3.0 becomes more polished, we can dedicate more resources into the R&D of new features. Here is a short list of what we have planned:

• Push notification via email, Telegram, Discord
• Asymmetrical encryption of contracts
• EthSign Lite & Finality Bridge
• EthSign Embedded Web API
• … and more!

Access EthSign Here
Twitter |Gitbook |Discord | Youtube

EthSign September Product Update was originally published in Sign on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are thrilled to present you with EthSign 3.0, a brand-new document signing experience available on 6 EVM-compatible blockchains:

• Avalanche C-Chain
• Binance Smart Chain
• Ethereum Mainnet
• Fantom Network
• Polkadot Moonbeam Alpha
• Polygon Matic

EthSign 3.0 is rebuilt from the ground up, making it the most versatile and useable version ever. A revamped UFFI provides an experience that is leaps and bounds ahead of our 2.0 release and the smart contract has been rewritten from scratch to accommodate the updated workflow and significantly improves performance and scalability all the while reducing gas fees.

For a full description and walkthrough of our 3.0 release, refer to our GitBook documentation here.

A Fresh User Experience

We completely redesigned the entire workflow and UI of EthSign 3.0 to make it not only more pleasing to the eye, but also more intuitive than ever to use. We looked to our Web 2.0 counterpart, DocuSign, and took inspiration. Our goal is to reduce user friction wherever possible and the best way to achieve that is to provide a sense of familiarity.

The overall redundancy in our user workflow has also been greatly reduced as the entire process has been streamlined to fit the most common use cases instead of trying to fit every single use case there is. Coming from the Web 2.0 world, users will feel right at home in our 3.0 release. The 3.0 menu has exciting new features such as: in-browser PDF preview, editing, annotation, and signing.

For a full description and walkthrough of our 3.0 release, refer to our GitBook documentation here.

Smart Contract from Scratch

Warning: Complicated technical mumbo jumbo ahead!

We won’t shy away from the fact that EthSign 2.0 has its fair share of issues. Apart from certain counterintuitive user experience fragments, the smart contract also suffered from unnecessary gas usage and most importantly, an over-reliance on Solidity events to keep state. As a result, just trying to view your current contracts can be painfully slow, sometimes so slow that the entire thing would time out. I dedicated an article detailing the causes, the issues, and how we addressed it in the 3.0 release.

Long story short, the 3.0 smart contract has been rewritten from scratch. Not only is it more secure, it is also way more detailed in its bookkeeping, enabling the users to quite literally turn back the clock and gain access to a version of their contract at a specific moment in time (if the file still exists on the decentralized storage platform), something that wasn’t possible in our 2.0 release.

We also designed our 3.0 smart contract with collaboration in mind —we have opened up our smart contract API so other developers can integrate EthSign deep into their projects and call our smart contract directly. For more details on our open smart contract API, visit https://github.com/EthSign/EthSign-3.0-API/.

In summary, our 3.0 smart contract has better performance, better efficiency, better security, and has been written with the goal of acting as an open service platform.

Speed and Power

One of the main problems dApps face is scalability and performance. In the Web2 world, this is quite a trivial topic as caching services and CDNs are readily available and those offered by the big players, such as Cloudflare or AWS, can be deployed with just a few clicks. This is not so easy in the world of blockchains and especially difficult when we want to try our best to avoid building a centralized caching server.

However, with our integration with The Graph, EthSign 3.0 has harnessed all the benefits of Web2 caching services while maintaining a high degree of decentralization. A network of indexing nodes now stand behind EthSign and help reduce our on-chain data load time from tens of seconds to just under 2 seconds. It really is quite the impressive feat that brings us a huge step closer to Web2 applications that we are all familiar with. Read more about our integration with The Graph here: https://medium.com/ethsign/decentralized-data-queries-ethsign-using-subgraphs-via-the-graph-for-real-time-blockchain-indexing-74133abe103f

EthSign 3.0 Post-Launch Content

We want to release EthSign as soon as possible for everyone to use and gather valuable feedback. Therefore, we decided to finish a minimal vertical workflow before expanding horizontally. In EthSign 3.0, users are able to initiate a contract signing session, invite cosigners, and have them sign the contract with their digital signatures. The signatures, however, are only available on-chain at the moment. After the 3.0 launch, we will add in the ability to write the cryptographically verifiable digital signatures onto the actual PDF files upon download. This is just one of the few things that we plan to further polish — here is a list of what we will prioritize:

• PDF annotation and customized stylized signatures
• Push notifications for our users
• Arweave & Sia Skynet integration for permanent contract storage

The Road Ahead

学如逆水行舟，不进则退。

This is an old Chinese saying which roughly translates to: learning is like sailing against the current, you either keep forging ahead or fall behind. This cannot be closer to the truth in the rapidly evolving blockchain world — keep up, or get left behind. EthSign 3.0 is here to stay for much longer than 2.0 as we feel it is mature enough and more closely aligned with our vision than ever before. However, it doesn’t mean we will stop iterating and building upon the 3.0 release. There are numerous features that we have planned which would build on top of the 3.0 release such as NFT endorsements, contract templates, SAFE/SAFT signing, and DAO integrations.

2021 has been an exciting year for us as we made the the leap from zero to one in terms of product and funding. Our team has also expanded from having just 5 part-time EthSigners in summer 2020 to 10 full-time EthSigners working diligently across multiple continents. We thank you for your continued support and cannot wait to share more news with you in the near future! You can give us Feedbacks here.

Please note that we have not audited our code yet as we are still in the process of rapid iteration, but feel free to try EthSign 3.0 out

All Ears for Feedback

Nothing is perfect and we are no exception. Despite rounds of internal validation, we still very much need your help refining and improving EthSign. A feedback form is implemented with this launch to gather all your thoughts and opinions while trying out our product, both good and bad. Your feedbacks are invaluable to us!

[Twitter] [Discord] [Youtube] [Gitbook]

EthSign 3.0 Launch — All Systems Go! was originally published in Sign on Medium, where people are continuing the conversation by highlighting and responding to this story.

From our debut during HackFS to closing the seed round, EthSign has come a long way, and so have I. As our product became increasingly production ready, many unforeseen challenges arose when deploying and using EthSign on a public network instead of a local development network, and one of which is properly scaling. Today, we shall dive into the most critical issue we faced and have since then resolved — the reliance on Solidity events.

What are Solidity Events?

Events in Solidity are essentially messages that gets broadcasted and permanently written onto the blockchain. They take in typed arguments so their contents can be populated dynamically at runtime and stored into the transaction receipt. For example, here is an event that EthSign emits when a new document is created:

event LogNewDocument(address indexed initiator, bytes32 indexed documentKey, uint256 birth, uint256 expiration);

The incentive to use events is clear — they are cheaper than on-chain storage and is incredibly easy to query, as we can filter events by the emitting contract, event name, and indexed arguments. Or so it seemed in the beginning, anyway…

The Ganache Trap

Ganache is a local development blockchain network that responds instantly to our queries and transaction calls. It is incredibly helpful for developers as it saves us time and hassle interacting with various testnets. Each account is initialized with 100ETH so funds will never run out. Developing and iterating on a local network is generally much more preferred but it does conceal quite a big problem — we will almost never get this kind of instant performance on actual blockchain networks and thus certain things that work perfectly on local networks run into a wall on actual networks, one of which is events querying.

There are two factors that affect how quickly events are queried a real blockchain:

• The number of blocks that needs to be scanned through: obviously, the more blocks you need to look at, the longer it will take.
• The bloom filter implementation: Ethereum makes use of a bloom filter to enable quick event indexing without leaving the block header, meaning by just looking at the block header a node can determine if an event is contained in this block. Some implementations yield much faster indexing times than others.
• RPC restrictions of that specific blockchain network.

On a local network, none of these issues exist primarily due to the extreme low block height (thanks to automine, which only mines a new block if a transaction is detected) and the fact that there is quite literally nothing else on the blockchain other than the smart contract we are testing. On a public network, however, things change. Blocks are mined at a regular interval all the time and certain networks have RPC restrictions in place that limits API query calls. On Binance Smart Chain, for example, their RPC limits the maximum number of block range in a query to 5000 blocks while on Avalanche FUJI C-Chain, the limit is 512 blocks. Furthermore, Binance Smart Chain’s RPC often returns an internal error, which means we would need to retry the previous query.

In summary, a simple event query that takes less than a second on the local network can take more than 20 seconds on a public network. To put things into perspective, scanning through a day’s worth of blocks on BSC takes at best more than 10 seconds, at worst more than 30 seconds due to RPC restrictions.

In EthSign 2.0, I heavily relied on events to keep track of state and power the core features of our smart contract. Want to know what documents you have initiated? We need to query. Want to know what documents are shared with you? We need to query. This over-reliance on events was not a problem during local testing but proved to be fatal once deployed onto the public network. Our smart contract was painfully slow to load and the longer it had been deployed, the worse it got.

A Bandaid and a Cure

The most immediate bandaid solution is to make use of a third-party indexing service that caches all events on their servers. When we need to query events, instead of reaching out to the blockchain network, we reach out to their servers and get a near-instant response. I found The Graph and Covalent to both be excellent services that solved the immediate problem of slow event queries. However, when we utilize a third party service out of desperation instead of convenience, it indicates something went seriously wrong elsewhere. In this case, the better and permanent solution is to revamp the smart contract to eliminate its dependency on events, at least for determining the current state.

Therefore, starting from EthSign 3.0, dependency on events has been completely removed. Through a series of mappings and enumerable data structures, the smart contract now internally keeps track of the current state, which makes loading documents instant as opposed to waiting and praying the RPC does not throw an error.

Using Events Correctly

This is not to say events don’t have a place in EthSign — they are still crucial for us to keep track of document history. This is totally fine though, as it is not common for users to regularly check document history. When users do decide to check the history, we can make use of The Graph and Covalent to quickly retrieve the needed events and populate the document history table.

Join EthSign on Discord

Scaling a Smart Contract — Events was originally published in Sign on Medium, where people are continuing the conversation by highlighting and responding to this story.