Case studies
About us

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:
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!

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.
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.
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.
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 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.
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!
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.
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.
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!
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.
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!
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!
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!
A hybrid of a social network and a music app
The first truly decentralized stablecoin crypto on Ethereum
A private inbox, wallet, and marketplace all in one
An identity verification MVP
Rumblefish Blog
Check a piece of expert knowledge
The Current State of Knowledge About Zero Knowledge. Comprehensive Private Token Overview - Part 3_BlogPostImageThe Current State of Knowledge About Zero Knowledge. Comprehensive Private Token Overview - Part 3
Oskar.jpg_BlogPostAuthorAvatarBy Oskar Karcz
This post is Part 3 of our three-part series dedicated to ZKs and Private Tokens. Click here for Part 1, and Part 2. Part 3: Return of the HashTheory vs practice. Expectations vs realityIn the previous part of the series, we delved into seemingly unrelated topics about blockchain, zero-knowledge proofs, and privacy. Now, let’s transition to practical considerations and explore the tools available for developers.Undoubtedly, the creation of any kind of ZK technology needs ZK Proof. How can we create it? The core element in this process is known as a circuit, often referring to an arithmetic circuit—an ordered collection of operations (such as addition, multiplication) represented by gates. In the realm of ZK-circuits, this translates to a program specifying a calculation to be performed on certain data inputs, used by the prover to generate a proof of knowledge. Thankfully we’re not forced to create every complex circuit from logic gates (AND, OR etc), but instead can use dedicated programming languages. Moreover, it's possible to validate the proof on-chain, using smart contracts deployed on platforms like Ethereum. Let's explore the available options:circom by iden3: designed for ZK-circuit development, circom provides programmers with a powerful and precise Domain-Specific Language (DSL). However, newcomers may find it challenging to grasp the syntax and semantics underlying the mathematical equations.Noir by Aztec: a language for Aztec, a privacy-focused Layer 2 for Ethereum, heavily inspired by Rust. Noir is designed to be user-friendly for developers without a ZK background.Cairo by Starkware: another language dedicated to Layer 2, Cairo is a relatively low-level "intermediate" language known for its efficiency and scalability.Zokrates: while not a language per se, Zokrates is a toolbox for zkSNARKs. It simplifies the complexity of ZK-circuits, aiding in generating proofs in high-level languages and verifying them through Solidity smart contracts.Other noteworthy languages include:o1jsLeoLurkAs evident, several options are already available, with more on the horizon! While developing on Layer 2 platforms like Starknet has dedicated languages, addressing the Ethereum Mainnet introduces intricacies due to subtle yet consequential differences between ZK and EVM elliptic curves. Let’s explain them now.Elliptic curves and straightforward hashesOnce again, in this series of articles, I don't intend to delve too deeply into this complex theme, as covering everything comprehensively would require another series of papers. Numerous excellent resources on this subject can be found on the internet. So, let's keep it as simple as possible.Blockchains like Bitcoin or Ethereum employ hashes as account addresses, which is obvious. However, not everyone understands how these addresses are created. It involves something like private and public keys, a touch of cryptography (or, as some might say, magic), and voila! Let's take a closer look.In mathematics, there's a concept known as elliptic curves. While these curves can take various forms, they are essentially a set of points that satisfy a specific mathematical equation, such as:y2 = x3 + ax + b.  Utilizing the cryptographic system known as ECDSA (Elliptic Curve Digital Signature Algorithm), it becomes possible to obtain a point on the elliptic curve (public key) through the multiplication of two numbers. One of these numbers represents the private key. The trick lies in the fact that calculating the public key from a known number (private key) is extremely fast, yet attempting to deduce the number (private key) from a given point (public key) is incredibly challenging. In essence, the public key can be derived through a one-way function from the private key.Click for resourceTo generate a public address for your account, simply append 0x to the beginning of the last 20 bytes of the Keccak-256 hash of the public key.The curve employed in ECDSA is named the secp256k1 curve, and what holds significance for us is that operations on this curve entail arithmetic with 256-bit numbers. Why is this aspect crucial?Zero-Knowledge Proofs and EVM Relationship Status: It’s complicatedRecall zkSNARKs, the proving system integral to Zero-Knowledge Proofs? zkSNARKs rely on elliptic curve cryptography, which permits operations only on numbers restricted to 254 bits. In summary, the numbers utilized on Ethereum's EVM surpass the 254-bit limits allowed in zkSNARK systems. Consequently, to implement ECDSA algorithms within ZK circuits, we must resort to 'non-native' field arithmetic.This presents one of the most significant challenges in ensuring a smooth interaction between ZKP and EVM. While it is achievable, there's always a trade-off: time or money. A noteworthy example is the commendable work by the 0xPARK Foundation, which presented an implementation of an ECDSA circuit in the circom language, capable of generating zkSNARKs. Although it is possible to prove ownership of an account, there is still much to be done, as the performance falls short of expectations. The circom environment is resource-constrained, making proofs expensive and time-consuming.Nevertheless, ongoing efforts have resulted in an improved approach to verifying ECDSA signatures in ZK. Spartan-ecdsa, introduced by Personae Labs, shows promise. It’s still a work in progress, with challenges like poor Keccak performance and excessively large proofs for on-chain verification via smart contracts still needing to be addressed.There is always hopeLet's pause for a moment and contemplate our goals and available options. The objective is to validate the proof (a 254-bit system) on-chain, which is a 256-bit system. Two potential approaches come to mind:Convert 256-bit numbers to 254-bit ones, as previously discussed. However, this option, as assumed, is currently impractical.Convert 254-bit numbers to 256-bit ones, which we will dive into below.Given that numerous encryption and description operations need to occur within zkSNARKs, necessitating 254-bit numbers for easy arithmetic, we can explore the utilization of another elliptic curve known as Baby Jubjub. Specifically designed to function efficiently within zkSNARKs on Ethereum, the ERC-2494 was introduced in 2020. Although it is no longer active, it remains a compelling and intriguing concept worth considering.A Bitcoin Orchard: Merkle TreesIn the realm of Zero-Knowledge Proofs (ZKP) on the Ethereum Virtual Machine (EVM), or more broadly, whenever we navigate the blockchain landscape, a critical consideration emerges: data storage. While the ability to create and verify proofs is commendable, it becomes even more enchanting when we can efficiently store those proofs on the blockchain. A widely adopted solution, employed, for instance, by Tornado Cash, is the Merkle Tree. This data structure proves invaluable for privacy-centric projects by securely storing hashed (encrypted) data fragments while enabling the verification of specific data without exposing the entirety of the dataset. Let's once again refer to the diagram for a clearer illustration.At its core, a Merkle Tree is a data structure crafted from encrypted (hashed) data fragments. Illustrated in the diagram, each pair undergoes a hashing process, generating the next "leaf" (node). This paired hashing repeats, ascending the tree until culminating in the top hash known as the Merkle Root. This ingenious structure facilitates the proof of data existence within the tree without necessitating the storage of the entire dataset. For an in-depth exploration, delve into this detailed explanation.Merkle Trees works great for the UTXO Model, because the entire state can be stored with two Merkle Trees:a Note Tree - stores all system data, including smart contracts and asset ownership;a Nullifier Tree - stores data about spent (used) UTXOs.Before using a UTXO, it's checked in the Nullifier Tree to ensure it hasn't been used. If all's clear, changes can be made in the Note Tree.Encrypt. Verify. Repeat. zkSNARKUnderstanding Merkle Trees is vital for comparing SNARKs on various circuits, especially if the criterion is hash verifying efficiency. The method of creating hashes within the Merkle Tree, however, is far from unequivocal; it hinges on factors like numerical systems (e.g., 256- / 254-bit), arithmetic complexity, and cryptographic security. The most prominent ones among many available hash functions are: MiMC - designed for very compact circuits with minimal amount of multiplications. Great for the tiniest circuits and as the base for more complicated algorithms (e.g. GMiMC),Poseidon - an enhanced version of MiMC with improved security, well-suited for scenarios requiring a collision-resistant, secure, and SNARKs-friendly algorithm,Pedersen - extremely useful and efficient, for e.g. homomorphic encryption, which enables solving some zk-security problems (like confidential payments) and building Merkle proofs. On the other hand, this can lead to significant security vulnerabilities.Segueing back to zkSNARKs protocols, two prominent players — PLONK and Groth16 — take the spotlight. For a detailed exploration of their nuances and functionalities, dive into this article. In a nutshell, both Groth16 and PLONK, are not quantum-resistant, and exhibit distinct characteristics: Groth16 boasts a generally smaller proof size, whereas PLONK sidesteps the need for recurring trusted setup ceremonies.Private Token: Proof of Concept Let’s see what the Private Token system could look like, using ZKP and EVM blockchain. Private Token is deployed as an EVM smart contract on a ZK-rollup (L2) and uses zkSNARKs to verify (on-chain via smart contract) transfer correctness and keep privacy at the same time. It is designed with the UTXO Model and uses Merkle Tree for membership proof. The Private Token contract maps UTXOs with commitments, having a structure defined by owner address, value, and unique ID. The ZK Circuit, written in circom language, verifies input and output UTXO values and sender ownership. As a result, we get a new UTXO commitment, in the form of data hashed with e.g. Pedersen Hash Function. If valid, a new commitment is added to the Merkle Tree using the Baby Jubjub curve (254-bit) for an efficient proof system. UTXOs are stored on Private Token contract in an encrypted format and thanks to the Partially Homomorphic Encryption can be decrypted and read only by the owner of the account.Simple, right? Well, if you're still a bit dazzled, no worries – I'm not grading anyone on their zero-knowledge prowess. Stick around, and we'll unravel more in the next posts!
Code stories
The Current State of Knowledge About Zero Knowledge. Comprehensive Private Token Overview - Part 2_BlogPostImageThe Current State of Knowledge About Zero Knowledge. Comprehensive Private Token Overview - Part 2
Oskar.jpg_BlogPostAuthorAvatarBy Oskar Karcz
This post is Part 2 of our three-part series dedicated to ZKs and Private Tokens. Please read Part 1 here. Part 2: The ZK Strikes BackMoney for nothin’ (... and the privacy for free)But why does it matter? Why delve into all these models and ownership concepts? Well, it's crucial when we aim to understand secure and privacy-centric transactions.As mentioned in Part 1, the UTXO model resembles a cash-payment system, while ETH's Account-Based model is more akin to a bank account setup. Which one offers better privacy? Certainly, it's the former. Cash transactions are visible to both parties (sender and receiver), and the only necessary data is the bill's value and its new owner's address. Simple as that. Moreover, the sender (Bob) and receiver (Alice) can arrange to transfer cash without meeting by utilizing a code-safe box. Bob places the money in the box, sends the code to Alice, who then enters the code to retrieve the money. Voila! It's private and secure.Now, let's explore how this straightforward example can evolve into a blockchain solution. The critical question arises: How can we verify that Bob genuinely owned that money before and/or didn't just print the bill and hack the system? Well, the solution lies in checking whether Bob owns the money and ensuring that Alice (A) and Bob (B) balances before the transaction are equal to their balances after the transaction, represented as A1 + B1 = A2 + B2. This is where the magic unfolds — enter zero knowledge proofs.ZKP. Zero Knowledge Proof.Thanks to the prowess of cryptography, one can prove the veracity of a given piece of data without actually revealing the data itself. If you've never encountered Zero Knowledge Proofs (ZKP), you might be surprised that it's possible. Yes, it's possible! Revisiting our example, Bob (the prover) can persuade Alice (the verifier) that he owns the money and the transaction is valid. Moreover, the entire system can acknowledge this proof, all without anyone discerning the specific amount of money and balances involved!Now, let's pause for a moment and delve deeper into the beauty of ZKP. While the concept is continually evolving (with much work still ahead), its roots trace back to 1985 when it was first introduced in the academic paper "The knowledge complexity of interactive proof-systems".From our perspective, the significance lies in ZKP's ability to address privacy concerns, allowing for the validation of claims without the need to expose sensitive information. For instance, it can be employed to verify your ID without revealing the actual ID ("I am Bob, here's the proof!"). To achieve this, the most basic structure of a zero-knowledge proof consists of three elements:Witness: This is the secret information that the prover aims to prove knowledge of without revealing it.Challenge: A randomly selected question posed by the verifier, which the prover must answer.Response: The answer calculated by the prover in response to the question asked.This interaction must be repeated multiple times to eliminate the possibility of the prover faking knowledge of the witness. Termed "interactive zero-knowledge proof," it necessitates back-and-forth communication between the prover and verifier. While this is effective, it might be inconvenient or even impossible in some cases. Fortunately, there's also a solution—enter "Non-interactive ZKP," which can be generated using a "shared key." This key can be passed to anyone for verification, minimizing the communication required between the prover and verifier, thus enhancing the efficiency of ZKP.zk-TYPEs Non-interactive proofs come in various types, and currently, two of the most compelling are:zk-SNARK: Zero Knowledge Succinct Non-interactive Argument of KnowledgeIntroduced in 2012 and employed by, for example, Zcash, zk-SNARKs are small in size and easy to verify (succinct). zk-SNARK generates a proof using elliptic curves cryptography (no worries, I will explain them later on!), which implicates two important things. Firstly, the proof-generating process requires a trusted setup, so the initial creation event of the keys is needed to create and verify the proof. This one is called the Powers of Tau Ceremony and is used to ensure security by using a multi-party computation (MPC) (more about setup ceremonies can be found here). Secondly, zkSNARKs are not quantum attacks resistant, which might be the case in the future. zk-STARK: Zero-Knowledge Scalable Transparent Argument of KnowledgeBased on hash functions, zk-STARKs stand out by being resistant to quantum attacks and not requiring a trusted setup, unlike zk-SNARKs. However, zk-STARK proofs have a considerably larger size than zk-SNARKs, translating to longer verification times and increased gas requirements.Zero Knowledge Proof - Full Utility CertaintySince its introduction, Zero Knowledge Proofs (ZKP) have found compelling use cases, and we'll focus on their application in the blockchain realm. ZCash, launched in 2016, stands out as one of the pioneers in privacy-oriented blockchains, as it was created as the solution for one of the biggest Bitcoin challenges: privacy. While Bitcoin leans towards pseudonymity, allowing for easy tracking of addresses and transactions, ZCash strives for true anonymity. Leveraging ZK technology, specifically zkSNARKs, ZCash conceals transaction amounts and addresses, offering a robust privacy solution (learn more here).ZK technology isn't exclusive to the UTXO Model; projects on the Account-Based model, especially on the Ethereum Network, have embraced it as well. Tornado Cash, a prominent example, acts as a mixer allowing users to deposit crypto from one address and withdraw it with another, thwarting attempts to link two wallets and track on-chain activity. While facing legal issues and security challenges, Tornado Cash remains an intriguing attempt at preserving privacy.Other projects like Consensys' "The Confidential Transactions" and EY's "Nightfall Project" approach privacy differently. The Confidential Transactions aimed to enable transfers with encrypted balances, concealing user balances. Sender and receiver addresses weren’t hidden though, both sides of a transaction had to communicate off-chain and users had to keep decrypted balances to not lose access to their funds, which made The Confidential Transactions not so user-friendly and thus unsuccessful. On the other hand, the Nightfall Project sought to recreate the UTXO Model on Ethereum's smart contract, employing a Merkle Tree to manage UTXOs and hide users' balances. Though facing challenges such as expensive transactions and synchronization issues, Nightfall evolved into a zk-rollup protocol in collaboration with Polygon, offering efficient private transactions on the Ethereum Mainnet without compromising transparency and security.Like a complete unknown, like a Rolling Stone… like a ZK Roll-up? As detailed on Ethereum's comprehensive content and resource page, Zero-Knowledge Rollups (ZKR) are Layer 2 scaling solutions designed to enhance throughput on the Ethereum Mainnet by relocating computation and state storage off-chain. ZKR bundles transactions into batches, executing them off-chain and subsequently posting reduced data to the blockchain.Remember the Blockchain Trilemma we discussed earlier? Layer 2 (L2) is a concept aiming to address Ethereum's scalability issues, essentially a separate blockchain extending Ethereum with inherited security guarantees. L2 typically comprises a network (separate blockchain) and a smart contract responsible for interacting with the underlying blockchain, such as the Ethereum Mainnet.Presently, two main Layer 2 implementations are considered the most promising: payment channels and rollups. Both aim to reduce transaction costs and enhance scalability by executing state changes off-chain and proving them on-chain.One can’t be surprised that scalability in rollups can be achieved in different ways and nowadays two types are being the most actively developed: Optimistic Rollup and ZK Rollup. Focusing on the latter due to its alignment with the Zero Knowledge theme of this article, ZK Rollups aggregate transactions, perform off-chain computation (generate Zero Knowledge Proofs) and send data to Layer 1 smart contracts for proof validation. This architectural approach accelerates and economizes transactions without compromising security.While this may seem overly complex, there are already working solutions like zkSync, Starknet, Loopring, and Aztec, with a total value locked exceeding a billion dollars (see ZK Rollup project summary).A significant challenge in ZK Rollups revolves around generating and validating proofs efficiently. How to create the proof as fast as possible, while keeping it not “too heavy” or not too expensive to verify (remember, this must be passed to the blockchain, and that costs money!)? This is exactly where the knowledge about zkSNARKs and zkSTARKs needs to be utilized to choose the most suitable technology for a project! For example, Starknet uses zkSTARK and Loopring is based on zkSNARKs. So, as you can see, it’s not such a trivial decision, especially when the technology is being developed so rapidly. This is Part 2 of our three-part series - stay tuned for its continuation!
Code Stories

We are a proud member of:swissPolishBlockchainIconpolishBlockchainIconTogether 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
We will answer any questions you may have related to your startup journey!Do you prefer e-mail?
RUMBLEFISH POLAND SP Z O.O.Filipa Eisenberga 11/3 31-523 Kraków, Polska
NIP: 6772425725REGON: 368368380KRS: 0000696628
P: +48 601 265 364E:
Copyright © 2024 Rumblefish