About Gambit
- What does Gambit App use?
- Browser vs. Desktop Applications
- Safety & Security
We use Electron. Electron is a framework which consists of two parts. The first part is the browser engine, used for rendering the application. Electron uses Chromium for this. Chromium is an open source version of the browser on which Google Chrome and Microsoft Edge are built. It uses the open-source Blink rendering engine and V8 JavaScript engine which is an open source project from Google (Some people call it Chrome V8 which is incorrect) (Source: https://v8.dev/). We also use the "back-end" of Electron which runs on Node.js. (Which also runs on the V8 engine). However this is different from, for example, a browser application. I will cover this in the next two questions. Besides V8, we also use Python, Rust and C++ for various situations to get the best performance.
It's fairly simple: we picked the best tool for our product. To explain our choice, I split it up in different categories: UI, UI performance, general performance, security.
TLDR: Every toolbox out there uses the same languages for their UI. Difference is: are they designing it for 500 transactions or 50,000 transactions. We design Gambit for the biggest runners and will always do anything to improve the UI performance.
Designing a UI in other languages than the main frontend stack (HTML/CSS/JS) is fairly hard. Why should we spend twice the amount of time getting something done when we also can do it much easier. I have been working on various other tools the last 2 years and the experience I got working on those has made Gambit possible. There are barely any tools out there with an easy usable and good looking UI, let alone the language they use for their UI. This doesn't mean that every application which uses this frontend stack will have a good UI and good performance. Getting good performance when you have 10,000 transactions running and updating every 200ms is quite difficult. You always see people testing with 10 transactions or listing 3 items but do you ever see people showcasing their UI while listing 1000 items or running more than 5000 transactions? I spent last week rewriting 50% of our application because I wanted it to handle more than 30k transactions with more than 5k updates every 200ms. I would rather launch a product that looks good, performs well and is built to be maintained than launch something quickly because you're scared of the competition or the pressure of customers. I still think we can improve our product and every developer who says his product is completely finished doesn’t listen enough to feedback.
If you aren't a big runner and just use it for getting that one NFT you like, performance isn't that big of a concern for you. I'm fairly sure that most toolboxes will do it for you and personally I would advise you to check every toolbox and compare them. Do you really need a toolbox which costs more than 2k while some other toolbox is 50% cheaper or free and basically does the same thing.
- If you're a smaller runner: please ask questions to all the teams about what the toolbox will cost and why you should pick them over product x. The security will be good enough in most of the applications and every product will say that they're the fastest. Look at the community around a product and see how the team responds to difficult questions. Developing software takes time and a lot of testing. Just because a product is finished, doesn't mean it's good. We delayed our first beta by almost 4 days just because we were not happy about the speed of loading assets and caching them. Good caching helps people who travel a lot or have a bad internet connection
- If you are a big runner: please ask the questions listed above. Also ask all the teams about how their toolbox or bot works if you run more than 500 mint tasks or 5,000 transactions. Ask the questions you need to know because every toolbox out there works well with 10 mint tasks or 20 transactions.
TLDR: Your browser is a browser which you use for running YouTube or OpenSea. Electron is the barebones of the browser without all the extra stuff and includes full control of your OS features such as saving files and better data/memory management.
Now about performance which drives me crazy because of various claims. Just because it uses the same engine doesn't mean the performance is the same. Just look up how the EA used the Frostbite engine for different games. Did you know they used the frostbite engine V3 for Fifa 17 but V2 for Battlefield 3? This is the same for JavaScript. Like I said, we used the rendering engine of Electron to render the UI. However most of the data processing is done on clusters. To explain what a cluster is and why a browser will NEVER get close to the same performance, let me first explain how JavaScript works.
(Following is simplified) JavaScript is single threaded which means that there is 1 thread of your CPU core processing data. This means that it can only calculate 1 thing at a time and it blocks other calculations in the callstack (basically a queue) till it completes whatever it is doing. (More info: https://codeburst.io/is-javascript-single-threaded-youre-kidding-me-80b11d74f4e5) Sometimes you have async code which means that, you need to wait till something is loaded, like fetching images. This happens on the same CPU thread but on a different queue. It's a beautiful system and I recommend every developer to watch this video: https://www.youtube.com/watch?v=8aGhZQkoFbQ
So how can you use multithreading? There are only TWO options for multithreading in JavaScript: web workers and clusters. Browsers only support web workers. Web workers are small workers meant to use for long running calculations. They run on a seperate thread (at least on all modern browsers) and have their own callstack (a queue) so they don't block anything in the browser. So why aren't we using web workers? Because beside web workers, Node.js (which is used inside Electron) also supports clusters. Clusters work exactly the same as web workers except they have a few advantages. First of all, they can use more OR less memory. Web workers in the browser have a limit on how much memory (DRAM) they can use but in Node.js we have full control over memory usage of a thread. What's even more important is that Electron is an application, so for multi-threading they can use the native OS thread scheduler to use threads. Why is this such an advantage? Because of libuv!
Libuv is a library which is part of the C++ side of Node.js. We can execute C++ code for more difficult operations or native OS operations. In Google Chrome they use libevent. C++ code can be anything like encrypting, fetching data or saving files. The only way you can use this in the browser is to use the JavaScript functions the browser provides which call the C++ functions implemented inside the browser. These are limited to basic browser functions such as fetching data. This means we can't use our C++ code for encrypting data or sending transactions with C++. This is possible in Node.js! However it's still not the main reason why we choose Electron over a website.
The C++ portion of Node.js is shared between all the web workers (same applies to libevent for Chrome), so if you make 1000 HTTP requests or use the OS file system to cache 500 images locally, it gets queued up in the C++ callstack. Except clusters get their own C++ callstack and threads! This means that when we create 1 cluster for every CPU core you have, those 1000 HTTP requests and caching 500 images will get spread over the clusters (for example 4 clusters) and suddenly there are only 250 HTTP requests in each cluster and 125 operations for saving images. People buy PCs of over $2000 dollars so why utilize only 10% of your PC when it's possible to use 50% or more? (Source: https://iamsongcho.medium.com/the-internals-of-node-js-b57bab6dc90)
And then we haven't even started talking about how we cache data locally and have no limit on how many images and data we can cache while most browsers have about a 2GB limit or x% of the available disk space. Sell an NFT? We only fetch the info of that single NFT and update it. Slow internet? No problem. We only load NFT assets and images first on the first load and after that we just update them if they change. If you have fetched your NFT image once, we store it on your drive and you never have to fetch it again. This means that your loading time will decrease a lot the next time you fetch your assets.
I'm gonna keep this nice and short: browser applications are just as secure as desktop applications which means they're both just as insecure. Claiming that you can inspect network traffic of a browser application means just as much as Apple claiming you can repair your iPhone. It is possible, but if you want full transparency you're in for some bad news. The code sent to your browser is minified and obfuscated. Information can be sent encrypted so it's unidentifiable to someone watching the traffic. Even if someone has access to the unencrypted file, some developer can hash someone's private key and send it as some unrecognizable id. There have been all different kinds of exploits on how to fetch data so saying your product is secure because it's a website is just straight untrue. Another option websites generally use is websockets. The communication of websockets can't be seen in the default dev devtools of browsers (and it can be encrypted too). We encrypt our users config instead of using indexedDB which I have used in other tools. Both are just as secure. If someone figures out your unique encryption key, you have a bigger problem because they have access to your pc. Same applies to IndexedDB. If they have access to that, they have access to your pc.
Other issues for browser bots is that the web server could be hacked and suddenly you have infected every single user. This is just as bad (or even worse) than infecting a binary file. Also if you allow a third party wallet to a website, they still can do everything if you allow it. It's the same as with phones. If you say yes to location sharing and sending your private information, they can do everything with it even though you don't want to. The only security is trust and this applies to all desktop and browser applications. Anybody telling you something else is unfairly promoting their product or hiding something.
We use Electron for Gambit because, with the experience we have, we can develop a good looking UI easily which can run many transactions. We focus on performance and running many transactions at the same time and not just 10 or 100. We choose Electron over a browser application because Electron gives us the opportunity to use clusters and C++. Clusters give us more performance and control about how we use them than web workers will give us. It also gives us the change to use native C++ code and use native OS features such as the file system for caching data and clusters with the OS thread scheduler with their own C++ callstack and threads. The security is just as good or bad as browser applications (depends on your own security of course).
Ask yourself the questions about the value of a toolbox. How much does it cost, is it mainly promotion or do the developers care about their product. Ask questions about how YOU want to use it. Look at the community and see how developers respond to questions. Ask constructive questions and compare tools for their features but also differences. The security will be just as good or bad as any other tool out there.
Last modified 3mo ago