Deep Research and Development

The emergence of blockchain-enabled AI agents has introduced exciting possibilities for decentralized autonomous systems. However, our previous discussions about production-ready blockchain AI agents revealed a significant limitation: while blockchain networks are designed to run on retail computers to maintain decentralization, modern AI agents often require high-end GPUs for running large language models. This fundamental tension threatens to centralize what should be a decentralized system. This article explores how Zero-Knowledge Transport Layer Security (zkTLS) can help resolve this contradiction by enabling secure, verifiable interactions with external AI services while maintaining the decentralized ethos of blockchain networks. The Challenge: Decentralization vs. Computational Requirements In traditional blockchain systems, nodes and validators operate on consumer-grade hardware, ensuring broad participation and true decentralization. However, the integration of AI capabilities,...

SNARKs represent a groundbreaking cryptographic tool that enables the verification of computations without revealing the inputs or the intermediate steps. SNARK is deeply rooted in mathematical principles, leveraging concepts like hashes, and curve operations, which are language-agnostic. While many discussions around SNARK implementations often revolve around Rust due to its popularity in the cryptographic community, it's important to note that SNARKs can be implemented and utilized in various programming languages, including Go. In this article, we'll explore SNARK interoperability, demonstrating how proofs can be generated and validated in both Go and Rust. SNARK in Go: gnark One prominent library for implementing SNARKs in Go is gnark . Gnark is a powerful library designed specifically for Go that facilitates the creation and verification of zero-knowledge proofs using the zk-SNARK protocol. It supports various proving schemes, with Groth16 and Plonk being o...

If you are familiar with a language like JavaScript, you tend to never think about how your variable is stored, except to deal with the scope of the variable. When you are making programs to run on a distributed system like a blockchain, you have to think about things a bit differently. Solidity works as a compiled language where each operation gets converted to a lower level opco which the EVM can understand an interpret. Every operation that you write on your program gets executed on every computer in the network, which is why every operation costs 'gas' to prevent spamming and infinite loops. In solidity, getting to know the machine readable operations and their associated cost literally saves you money. Gas optimization is a challenge that is unique to developing Ethereum smart contracts. To be successful, we need to learn how Solidity handles our variables and functions under the hood. Some of the techniques we cover will violate well known code patterns. Before opt...

Today we'll continue the JavaScript Design Patterns series by discussing the Adapter Pattern . Adapters are added to existing code to reconcile two different interfaces. They allows programming components to work together that otherwise wouldn't because of mismatched interfaces. Adapter may be also used to ease the use with the existing interface. If the existing code already has an interface that is doing a good job, there may be no need for an adapter. But if an interface is unintuitive or impractical for the task at hand, you can use an adapter to provide a cleaner or more option-rich interface. Let's see how it looks in the following illustration: Here we depict the example of legacy  IDataManager interface, which is deeply used within the system. With the introduction of Redis database into the system, we need an adapter to fill the gaps. Our Adapter class has to implement the getData method, to make it consistent with the system, calling in turn the scan ...

In the previous articles we discussed Factory , Builder  and Prototype design pattern . Today it's time to draw a line under creational design patterns by talking about Singleton Pattern . Even though it's the most well known design pattern among the developers, the thought of writing one in JavaScript, makes most developers tremble. Naturally there is no reason for that and in fact implementing it is not that big of a deal. But first, let's see how it looks in the following illustration: Basically our singleton contains one instance of itself and returns only it. Client cannot create a new instance or get other instance then one proposed by singleton. So how do we implement it? The same way, like in any other language - using static classes. To brush off the rust, please read Object Oriented JavaScript article. var Singleton = (function () { var instance; function createInstance() { var object = new Object(); return object; } ...

Let's continue our discussion about JavaScript Design Patterns. We've already talked about Factory and Builder pattern . Today I'll overview the Prototype pattern . The Prototype pattern creates new objects by cloning one of a few stored prototypes. The Prototype pattern has two advantages: it speeds up the instantiation of very large, dynamically loaded classes (when copying objects is faster), and it keeps a record of identifiable parts of a large data structure that can be copied without knowing the subclass from which they were created. Have a look at the following illustration, depicting the pattern: While there is a lot of information about cloning on the internet and even some suggest using it in the prototype design, the external approach is utterly incorrect. However since we are Object Oriented programmers, we would like to clone both public and private members. None of the external approaches will give you such result. On the other hand, if you will...

Today I would like to continue the series about design patterns we started with Factory Patterns in JavaScript and talk about the Builder pattern . For some reason it's being left behind in any design pattern usage in JavaScript. Maybe it was correct in the front end domain, but surely not in Node.js. Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. The Builder pattern is based on Directors and Builders . Any number of Builder classes can conform to an IBuilder interface, and they can be called by a director to produce a product according to specification. The builders supply parts that the Product objects accumulate until the director is finished with the job. I'll be using the example from the factory pattern article to emphasize the differences between the patterns. Consider the class diagram for the Builder pattern: And the implementation: funct...

Since June has 5 Sundays in it, today I will write a bonus article :) Following our last week's article about Publish and Subscribe Pattern with Postal.js , I'd like to broaden the topic talking about design patterns . The design patterns from the Gang of Four book offer solutions to common problems related to the object-oriented software design. It has been in use for decades and implemented in all server side languages. It's time we use them with JavaScript and start to write some piece of decent code. I'll be writing a series of articles covering all of them. As in the book, we'll be starting with creational patterns  and cover both Abstract Factory and Factory Method patterns. Abstract classes and interfaces enforce consistent interfaces in derived classes. In JavaScript we must ensure this consistency ourselves by making sure that each 'concrete' object has the same interface definition (i.e. properties and methods) as the others. Abstr...

Last week we talked about testing JavaScript Testing with Jasmine  and today I'd like to continue our conversation about testing rather from different angle - separation of concerns . Once the code slips developers' fingers, it is hard to find time and strength to rewrite, it making it more testable. What works, may never be rewritten, sounds a bit like Iron island refrain  What is dead, may never die :) Hmm - sorry for that! Nearly all today's applications have some calls to somewhere to retrieve the data. Front side retrieves from the server. Server side retrieves from services or database. Some manipulate it, others just format it and present as it is. Take a look at the following examples: function someLogic() { $.get("ajax/test.html", function (data) { $(".result").html(data); }); } function someLogic() { dataManager.getClients(function (err, data) { if (!err) { doSomething(data); } }); } How can you test it? First of all th...

Last week we talked about JavaScript inheritance  and if you recall we had talked about modular design patterns in JavaScript  just a month ago. I would also like to talk about how to connect both modules and class inheritance. We've already discussed that modules are classes. So if we can link classes by inheritance relationship, the logical half of our brain suggests that we should be able to link modules as well. The logic prevails - we can. AMD and inheritance I'll be using the classes we defined in the inheritance article, Mammal and Dog , and create modules from them. Let's start with our super class: (function () { 'use strict'; define(function() { function Mammal() { this.age = 0; console.info("Mammal was born"); } Mammal.prototype.grow = function() { this.age += 1; console.log("Mammal grows"); }; return Mammal; }); }()); Let's use it in our entry point JavaScript file. Just t...

Last week we've discussed how to create classes and namespaces in JavaScript. For those who missed it, you can read it here . There is however something else you need to know regarding the topic, which is modules. Modules When we say an application is modular, we generally mean it's composed of a set of highly decoupled, distinct pieces of functionality stored in modules. Module can and are implemented using classes, which we already know how to define. So what is the problem? When you try to build a complex piece of software, you end up with hundreds of classes. All of them somehow interact with one another and since JavaScript is not compiled, your job is to reference and load these classes in a correct order. This is why module loaders specification was invented - the most prominent of which are CommonJS and AMD . CommonJS Currently, CommonJS is a de facto standard. Many third-party vendors are making modules or module-load systems according to the CommonJS...