Menu
Services
Products
Careers
Resources
Software development tailored to your needs!
Rumble Fish helps entrepreneurs build and launch bespoke digital products.
We take care of the technology, so you can focus on your business
Join the ecosystem
of our satisfied customers:
of our satisfied customers:
Who we are?
Hi there! We're Rumble Fish - a team of world-class experts in bespoke software development. Our engineers are highly skilled in blockchain, cloud solutions, and defi/fintech development. Our strength and pride is the ability to take ownership of the entire development process and be a true partner and advisor for our customers. Our mission is to craft state-of-the-art digital products using battle-tested technologies. Try us!
0Employees
0Projects
0Years in business
0Lovely dogs
0Cozy office
What do we do?
Software Development Services and Skills for your needs To deliver the highest quality of services, our experts are always
gaining new skills and knowledge. That’s how we make sure our
solutions follow the latest industry standards and take advantage
of the most innovative technologies.
AWS Cloud Solutions
Our experienced team will take your AWS cloud solutions to the next level. AWS provides purpose-built tools to support your needs, and it is the preferred choice for any blockchain project. From the plethora of cloud tools and solutions offered by Amazon Web Services, we’ll help you choose and implement the ones that serve your business the best way possible.
Web Development
If you’re in need of professional web development services, look no further! Rumble Fish's talented team has extensive experience in delivering top-tier web apps and websites with the use of battle-tested tools and technologies like React or Nest. We know just the right solutions to exceed your business requirements.
Mobile App Development
Whether you need an Android, an IOS app, or both, the Rumble Fish team is here to help you deliver the beautiful and efficient mobile product that your customers will simply love to use! We craft fast and secure mobile apps with a wow factor to help our customers grow their businesses and reach their goals quicker.
AI Chat Assistant Development
AI chatbots can bring value to a wide range of industries by enhancing customer interactions, streamlining processes, and improving overall efficiency. We'll craft a perfect AI assistant for your product.
DeFi Development
Decentralized Finance (DeFi) development requires an extensive amount of blockchain knowledge, as well as a great understanding of financial mechanisms. We’ve got both that bases covered! Our team has successfully built an impressive number of DeFi products like cryptocurrency exchanges, dApps, lending protocols, or staking platforms. Try us!
NFT Development
Rumble Fish engineers are experts in Non-Fungible Tokens (NFT) platform development. With our deep understanding of crypto, blockchain technology, and smart contracts protocols, we are able to take your NFT marketplace idea and craft it into a beautiful, state-of-the-art product.
Fintech Software Development
Looking for a skilled team to help you build an advanced fintech platform able to compete with the biggest in the game? At Rumble Fish, we’ve got what it takes to engineer innovative financial technology systems. We offer end-to-end fintech software development, consulting, and expertise.
Blockchain Software Development
Our team is well-versed and experienced in various blockchain development tools and technologies. Our unique skillset allows us to be at the forefront of Web3 development services so if you’re looking for a trusted IT partner to boost your decentralized product - look no further!
Dedicated Development Teams
Our experts provide you with knowledge, skills, and experience that elevates every project to another level. We’ll gladly take ownership of the entire process and guide you and your team through the intricacies of cutting-edge technology development.
UI/UX
We design sleek, intuitive, and highly effective interfaces to help you overcome your business challenges. After carefully evaluating and understanding your requirements we switch to the designing mode - the end goal is the beautiful digital solution that people love to use!
IT services for your startup
If you're looking for a team capable of turning your product concept into a beautiful and technologically intricate digital solution - look no further! Rumble Fish is your trusted software development partner ready to take you through the entire process of custom digital product creation - from the early stages of ideation to the post-launch support. Whether you're on a mission to build a mobile app, a Web3 product, or an advanced platform - we are here for you!
Testimonials
See what our customers say about working with us“
Latest case studyCustom AI assistant development
Custom AI assistant development
The main objective was to create an AI chat assistant to engage in intelligent conversations with legal documents stored in our customer’s internal databases. The goal was to streamline document analysis and enhance legal discourse efficiency.
Collaboration timeframe:2 months
Services:AI chatbot development
We're trusted by global innovators and leaders.Join them!
TURNTABLE
A hybrid of a social network and a music appTURNTABLE
MAKERDAO
The first truly decentralized stablecoin crypto on EthereumMAKERDAO
ZBAY
A private inbox, wallet, and marketplace all in oneZBAY
VERIFYID
An identity verification MVPVERIFYID
Rumblefish Blog
Understanding Account Abstraction Schnorr Multi-Signatures
By Oskar KarczIn today’s article, we continue the journey through public and private keys, blockchain algorithms, and Account Abstraction. Let’s focus on the complicated matter of ECDSA signatures and how to enable multisig transactions on Ethereum, shall we?Have you ever seen Vitalik sad?Or have you ever seen Vitalik angry?It looks like Ethereum’s signature algorithm is quite exciting and not that straightforward even for its co-founder. In this blog post, we’re going to discuss why ECDSA is (in some ways) not that efficient, why Bitcoin already adopted another algorithm called Schnorr, and last but not least, I’ll show you what solutions are already available and developed by amazing Rumble Fish devs!Let me do sign it for you!For those of you who are not familiar with blockchain’s private-public key pair concept, don’t worry! Relax, grab a big cup of coffee, and let me guide you through this! Ready? Let’s go!Every blockchain’s security, including Bitcoin and Ethereum, relies on cryptography and some brilliant underlying concepts. One of them is private-public key pairs which are used mainly for:authentication - to prove that the user knows the private key, which confirms their identity,encryption - to decrypt and read the message previously encoded, in other words - to read a secret message that only a private key owner can see. Private-public key pairs are asymmetric which means that with a given private key (think about it as simply as a number) it’s possible to derive the public key (the other number). However, it’s not feasible to reverse the process and get a private key from the public key. If you wonder why, take a look at our previous blog post, where I explained the magic behind elliptic curves and generating Ethereum addresses from private keys. To move forward I assume that ECC (elliptic curve cryptography) and ECDSA (Elliptic Curve Digital Signature Algorithm) acronyms already sound familiar to you. pov: ECDSA is a bad signature algorithmAs we’ve shown above, Vitalik himself believes that ECDSA is a bad algorithm. Let’s take a look at the reasoning behind this statement.In Ethereum, ECDSA is used as the algorithm for creating and verifying digital signatures. This is to ensure transaction authentication, so we know the transaction was approved by the sender. ECDSA uses the SHA-256 hash function and the secp256k1 elliptic curve and does it for good reasons. Firstly, it is constructed in a special non-random way, which results in efficient and fast computations. It provides strong security while requiring relatively little computational power. Secondly, the secp256k1 curve reduces the possibility of potential backdoor weakness and is also used by Bitcoin, so was already adopted at the moment of Ethereum creation. Now, let’s see what the basic process of signing and verifying a message looks like:Signing the message:Generate a private-public key pair. Keep the private key hidden and share only the public key.Calculate the message hash with a cryptographic hash function, e.g. SHA-256.Sign the message with the private key. By signing I mean performing a series of mathematical operations on the message hash value and the private key, which results in a unique signature.Transmit the message and its signature.Verifying the signature:Calculate the message hash the same way it was hashed within the signing process.Recover the signer address from the signature and public key (for the sake of simplicity I’m not gonna explain all the math behind it - I encourage you to do your own research).Compare the recovered address with the provided one - if they match, the signature is valid!So far it’s all looking good, right? So what’s the problem with ECDSA? The chaos appears as soon as someone wants to create a multi-signature. Ekhm, excuse me, multi-what…? - you ask? Let me explain.Multi-signatures - single problemThe Multi-signature Scheme is a concept that avoids a single point of failure and requires multiple signers to approve a transaction. This is great for splitting the responsibility of ownership of an address (and its funds) and can be shared between multiple people with different private keys. What's more, it’s possible to implement a k-of-n policy, so e.g. 2-of-3 means that only 2 signers (out of 3) need to approve the transaction for it to be valid (as shown below). This is commonly known as the threshold scheme.There are already plenty of multi-signature wallets, like The Consensys multisig wallet, Safe, or Argent. Most often that kind of wallets use a smart contract that stores multiple signers' addresses and verifies the signatures one by one (naive multi-signatures). And that’s the core of the problem. Why? First of all, storing multiple signers’ addresses costs money (welcome to the blockchain!), and the same goes for sending and verifying multiple signatures. Every signature needs to be verified with a specified signer separately and computational power is the crucial aspect of the transaction cost. What’s more (and in some cases the worst) signers’ public addresses are exposed and can be easily used to check who (out of the signers group) approved the transaction and who didn’t. OK, so what about aggregating multiple signatures into a single one? Well, this might be a better approach, but aggregated signatures are currently slower than e.g. ECDSA, so there must be a tradeoff between speed and size (which on the blockchain means cost).Bitcoin’s Taproot and Schnorr’s SignaturesLet’s jump out for a second to the Bitcoin Blockchain and look closer at one of the rare protocol updates, called Taproot. This BIP (Bitcoin Improvement Proposal) introduced several enhancements, including the Schnorr Signatures. Why do I mention this? We must realize that Bitcoin’s upgrades are extremely limited to keep the protocol stable and secure, so enhancements are deeply discussed, battle-tested, and significantly improve the network’s efficiency. So what is that Schnorr Signature?It is a type of digital signature scheme that allows for signing transactions in a very efficient way without compromising on security even for multi-signatures. The algorithm itself isn’t new though, because originally it was described by Claus Schnorr in 1991. It wasn’t widely used before because it was protected by patent till 2008 (the same year Bitcoin was launched).The primary advantage of Schnorr signatures lies in key aggregation. In a typical digital signature scenario, a single public key, message, and signature are involved, confirming that the owner of the public key signed the provided message. However, when multiple parties aim to sign the same message, like when spending from a multisig address, each must include their public key and signature. Consequently, if three parties wish to sign a message, the verification process entails three public keys and three signatures, leading to inefficiencies in computation and storage. Each node must conduct signature verification, a resource-intensive task, three times, and store three sets of signatures and public keys.Key aggregation resolves this inefficiency by obviating the necessity for multiple public keys and signatures. Schnorr public keys and signatures can be aggregated so that, if three parties intend to sign a transaction, they can combine their public keys into a single one, using their respective private keys to sign the same message. Subsequently, they can combine their signatures into a single signature valid for the aggregate public key. A verifier needs only to authenticate a single signature and public key to ascertain that all three parties signed the message.Signatures with benefits Key aggregation presents an opportunity to decrease transaction costs and enhance the scalability of the base layer, as signatures from multi-signature configurations occupy the same space in a block as those from single-party transactions. This aspect of Schnorr can be leveraged to decrease the size of multisig payments and related transactions (e.g. those within the Lightning Network channels).Moreover, Schnorr signatures possess a crucial attribute of non-malleability. In the realm of digital signatures, malleability refers to the capacity of an attacker to alter a confirmed signature in a manner that retains its validity while authenticating a distinct message from the original signature. Such manipulation could lead to significant issues in cryptocurrency applications, potentially allowing a malicious actor to increase the transferred funds' amount or change the recipient.Last but not least, Schnorr offers substantial privacy advantages. By enabling the obfuscation of a multi-signature scheme, rendering it virtually indistinguishable from a traditional single public key, Schnorr significantly complicates the task of differentiating between multisig and single-signature transactions through on-chain observation. Additionally, in setups involving n-of-m multisig, Schnorr makes it more challenging for observers to ascertain which participants did or did not sign a transaction.Just do it!Okay, that’s enough of the theory, let’s see what the practice looks like! As was written, the Bitcoin protocol already supports Schnorr Signatures and can be used alongside ECDSA. Unfortunately, the Ethereum blockchain does not yet, so this looks like a perfect opportunity for Rumble Fish developers to do, once again, some innovative stuff!No, wait a sec. Let’s complicate things a bit so that it’s not too easy. Where would be the perfect place to use multi-signatures? Where can we find the need for a multi-owner wallet? Any ideas? Exactly, Account Abstraction! Take a look at our previous blog post about ERC-4337 to see what it is and let’s move to the coding part!Let’s see what has to be done to achieve Multi-Schnorr-Signatures. Deploy MultiSigSmartAccountFactory and create Account AbstractionThis is needed to interact with the blockchain and use the Account Abstraction concept. In our case though instead of a single Account Owner, there are multiple Schnorr-Signers Owners. Create Schnorr Signers and MultiSig Account SignerTo utilize multi-signature features and be ERC-4337-compliant, the Schnorr Signer needs to be created out of an individual's private key.Construct User Operation CallData and build User OperationAs ERC-4337 specified, instead of standard transaction the User Operation needs to be created.Initialize Multi-Sig Schnorr User OperationCrucial element of multi-signature mechanism. To be sure that the same transaction is approved by every needed signer, the desired Multi-Sig Schnorr User Operation is created. It contains such information as transaction data and each signer’s public addresses, one-time nonces, and signatures.Sign the transaction by each defined signerTransactions can be signed by each signer in any order. There’s also no time limit or need for all of the signers to be online at once. Send the User OperationIf a transaction is signed by each needed signer, it can be sent through the MultiSigSmartAccount contract. As needed it can be paid by ERC-4337 Paymaster. User Operation data can be signed and used only once by design!Appreciate the beauty and simplicity of the Account Abstraction Schnorr Signatures solution. As simple as that!But if you are curious about how it works under the hood or want to utilize this in your project, feel free to jump into Rumble Fish repositories:aa-schnorr-multisigaa-schnorr-multisig-sdkThat’s it! Today I’ve showcased the pain points and vulnerabilities of the ECDSA signature algorithm when it comes to creating multi-signature transactions. I’ve also taken you on a journey through Schnorr’s Signatures and how to tie them into Account Abstraction to create an effective multisig transaction on Ethereum. Stay tuned for future updates and feel free to reach out to our team if you have any blockchain-related questions!
What is Account Abstraction and Why is It Important? EIP-4337 Explained
By Agnieszka DoboszAccount abstraction in Ethereum represents a groundbreaking shift in how users engage with decentralized applications (dApps). It introduces a novel paradigm where assets can be exclusively held by smart contracts rather than externally owned accounts (EOAs). At the heart of this innovation lies the ERC-4337 standard, which unlocks the potential of smart contract crypto wallets on the Ethereum blockchain.This article delves into Ethereum's account abstraction, exploring how it redefines user experiences with smart contract wallets and understanding the ERC-4337 standard within the Ethereum ecosystem. Let's dive into the history, evolution, and benefits of account abstraction, and its implications for driving a Web3 revolution. Back to the basics and why do we need Account AbstractionTo get to the bottom of Account Abstraction we need to take a few steps back and look into two main types of accounts on Ethereum:EOAs (Externally Owned Accounts) - used to store and transfer ETH, ERC-20 tokens, and other digital assets. They are controlled by an Elliptic Curve Digital Signature Algorithm (ECDSA) key, which is cryptography used to sign and verify digital transactions and involves generating a private key and a corresponding public key. (We’ve previously written more about ECDSA here). EOAs are managed using a public-private key pair, where the public key is the 64-byte (128 hex character) from which the network address (20-bytes) with the added prefix 0x is derived and is used by others to identify the account for a transaction. The private key is a mathematical key (kept secret by the holder) used to sign transactions and should be known only to the owner of the EOA. Basically, EOAs can only perform two operations: transfer native tokens to other externally owned accounts, and initiate transactions that prompt the execution of another smart contract transaction. This mechanism opens an account to many vulnerabilities and limitations, poor security being the most crucial one. If the account owner loses the private key and seed phrase, they may lose access to all their assets. There is no social recovery mechanism, no spending limits to set, and no 2FAs to add. Another drawback of EOAs is the lack of customization - owners must sign every transaction manually. On top of that, the EOA owner must possess ETH to cover gas fees. All of those make for an unsatisfying user experience, not very welcoming for users outside the Web3 world.Smart Contract Accounts (SCA) - in the simplest terms SCAs are smart contracts functioning as crypto wallets. They are fully programmable and are not controlled by a private key but by a customizable verification logic which opens the way to a variety of new possibilities. SCAs enable transaction customization and add extra features to the wallet, but due to the fact they don’t have a private key and/or seed phrase they cannot initiate transactions. The execution of a specific action is only possible when the smart contract code is triggered by a transaction from an Externally Owned Account (EOA). This basically means that users have to keep an EOA topped up with some ETH (or other native token) to run a contract account. So, dealing with a contract account ends up being even more of a hassle compared to handling a standalone EOA.Enters… account abstraction! Account abstraction, a concept described in the ERC-4337 proposal, offers a new approach where a smart account can be tailored to specific user needs using smart contracts but without the need for an existing EOA account. How is that possible? Let’s dive a bit deeper! 🐟 Introducing UserOperation, Bundlers, and PaymastersEIP-4337 introduced a couple of new features that enabled major upgrades all without any required changes to the Ethereum protocol. One of the said features is a new object type called UserOperation. Instead of shooting off regular transactions like an EOA would, UserOperation can handle operations on behalf of users. UserOperation objects carry data and multiple instructions to execute smart contract calls initiated by the smart contract account. They're then dispatched into a dedicated mempool where validators, referred to as "bundlers", gather them up into a "bundled transaction”. A bundler monitors the special mempool designed for UserOperation objects, bundling them into a single transaction sent to the EntryPoint contract. They receive compensation in the form of a portion of the gas fees for this service. Bundlers play a vital role in the account abstraction workflow because EAOs are still required to initiate all Ethereum transactions. Moreover, all bundlers possess EOAs, making them the sole participants needing them within this account abstraction ecosystem. This approach effectively abstracts the necessity for every Web3 participant to have their own EOA. Et voila!A moment ago, we mentioned an EntryPoint contract. EntryPoint, as a smart contract, receives transactions from bundlers and handles the verification and execution of UserOperations. In the verification phase, it checks if the wallet holds sufficient funds; if not, the transaction is rejected. For execution, EntryPoint executes UserOperations by invoking the smart contract wallets with the call data of the operations. Additionally, EntryPoint deducts funds from the account to reimburse the bundlers.Another new addition, introduced in EIP-4337 proposal is Paymaster, tasked with managing gas payment policies. These policies offer options on who foots the gas bill and how it's done. As a result, users aren't obliged to hold the native ETH token to engage with the network anymore. It’s a significant improvement for new users, entering the world of Web3 for the first time. Benefits of Account AbstractionNow that we have a basic understanding of how Account Abstraction works and what mechanisms it utilizes, we can focus on what it actually brings to Web3 users.Improved securityRight now, Ethereum accounts rely on a seed phrase and private keys to handle transactions. If that seed phrase takes a hike, there's no getting your accounts back, setting spending limits, adding whitelist accounts, or freezing accounts for extra security measures. But with Account Abstraction, developers can get crafty and program all sorts of options for account authentication and recovery. Lower barrier to entryFor folks who aren't familiar with blockchain, understanding the ins and outs of EOAs can pose a challenge. Properly managing and protecting their keys can be complex and leave them susceptible to vulnerabilities. However, thanks to Account Abstraction, developers have the flexibility to implement different logic to integrate security features and allow users to customize how they process and authenticate transactions.Enabled customization and automationWhen it comes to the current externally owned account (EOA) setup, users are stuck with transactions that can't be customized or automated. Each one has to be signed off individually. But with account abstraction, the game changes. Now, users can set up recurring payments and dive into other forms of automation. With EOA, you need to approve and authorize each transaction one by one. Imagine if you're into gaming or anything that involves a lot of transactions – it's a real time-suck and not all that convenient. But with Account Abstraction, things start looking up. You'll be able to greenlight multiple transactions with just one go, kind of like bagging a bunch of items with a single payment. Account Abstraction empowers developers to craft "wallets" that are non-custodial yet deliver a straightforward, intuitive, and dependable experience for end-users. DeFi apps can sport a user interface reminiscent of banking apps, where users are relieved of concerns regarding key management, gas fees, and other complexities. That's the ticket to making life easier for users diving into Ethereum and Web3 apps!Upgraded gas fee management optionsRemember Paymasters from earlier? Thanks to this feature, smart account users can cover gas fees with any ERC-20 token they fancy. Plus, anyone can chip in to foot the bill for someone else's transactions, dApps can even cover their users' gas fees as a thank-you, sponsorship, or just to keep things smooth sailing for users hopping onto their app. That’s the customer-first approach we all love! ConclusionIn summary, Ethereum's Account Abstraction marks a significant milestone in blockchain technology, offering users unparalleled flexibility and security. As developers delve deeper into its capabilities, the prospects for account abstraction appear promising, steering the evolution of Web3 toward widespread adoption.In the next part of this series, we’ll take a look at the most promising projects powered by Account Abstraction, including one of our own - Devil Wallet, a mobile Web3 wallet utilizing EIP-4337. Stay tuned!
Check a piece of expert knowledge
Understanding Account Abstraction Schnorr Multi-SignaturesBy Oskar KarczCode stories
What is Account Abstraction and Why is It Important? EIP-4337 ExplainedBy Agnieszka DoboszBusiness stories
We are a proud member of:
Together with our partners we're working to create a networking space for blockchain enthusiasts and share our knowledge and experience in building blockchain-based solutions.
Have an idea?
Let’s work
together!We will answer any questions you may have related to your startup journey!Do you prefer e-mail?
hello@rumblefish.pl
together!We will answer any questions you may have related to your startup journey!Do you prefer e-mail?
hello@rumblefish.pl
RUMBLEFISH POLAND SP Z O.O.Filipa Eisenberga 11/3 31-523 Kraków, Polska
NIP: 6772425725REGON: 368368380KRS: 0000696628
P: +48 601 265 364E: hello@rumblefish.dev
Copyright © 2024 Rumblefish