Kiran Kumar B

Hey there. I'm Kiran Kumar B. I'm a senior software developer working currently in CoffeeWins, Bengaluru. I have professional experience of around 6 years, in which the initial 2 years, I worked as an associate technical instructor in one of our own software, which my friends and I started when we were graduating. Later, I worked with Amdocs as an associate engineer, where I worked with back-end systems like the order management system. And later, I joined Cloudworks, which is a start-up, where I got a complete exposure to various technologies and tool stacks, where I transformed myself into a complete back-end developer working with various programming languages, starting with Python, then moving on to Node.js, and finally expertizing in Golang. Along with programming languages, I worked with various other databases, like PostgreSQL in terms of relational databases and MySQL for some projects, and essentially MongoDB for many of the projects where we needed Node.js-supported back-end. Along with this, I have a good hands-on experience in building REST servers, which support high user capabilities, and gRPC services to enable distributed systems and microservice architecture systems, so they can robustly scale up and acquire larger customer bases. After Cloudworks, I've been working with CoffeeBins, where my primary concerns are with respect to building the blockchain systems in which I have got expertise in Hyperledger Fabric, where we play with the source code itself. We have implemented various techniques to increase the TPS of the system, that too up to 3 folds of the existing ones. I have spearheaded many of the chain code development programs and will be leading a team of 4 in improving the efficiency of the existing Hyperledger Fabric system and writing down the chain codes or business contacts to implement them in the applications of a very big Fintech joint. Along with that, I have experience in working with other systems like building Google Smart Home applications, Alexa systems, and even starting from building command-line interfaces, simple command-line interfaces. My expertise goes majorly with back-end development, which includes various programming languages and databases. Along with that, I have a good knowledge of networking and containerization using Docker and a bit of knowledge in Kubernetes, where we use for Docker container orchestrations. I have worked with AWS and Azure as cloud providers. And I have an understanding of GCP, which I used for Google's model development. So along with that, I have an understanding of front-end development, like I understand HTML, CSS, and have an understanding of Vue.js, which I learned when coordinating with the front-end developers. And I can coordinate with the mobile application developers because I have worked with Flutter developers out there. And these are various technologies that I have worked with previously.

We can implement a secure breaker pattern in Node to prevent failures while interacting with blockchain systems mainly by monitoring the application we are communicating with. In a blockchain system, as a client, we will be directly communicating with the server using the gRPC network, especially when communicating with the Hyperledger Fabric server and the Node.js client. So we'll be communicating using gateway servers, which is a gRPC network, and we can monitor every stage of the transaction. The beauty of the Hyperledger Fabric SDK is that we have control over each stage of the transaction. That is where we prepare a transaction payload and when we submit it for endorsement, then submit it for ordering, which further goes to validation. We have a segregated way, so we can look into the errors that we face at the various stages. I take up the call to break down the circuit communication there. Apart from that, considering systems like Hyperledger Fabric, which are permissioned blockchain networks, whenever the system receives any request from a client, it will have the identity of the requester, which has nothing but is a public key. The any data request from the client will be assigned by the specific user. So we can make use of this data to rate limit the requests that are being sent from the client, and hence, we can break down those communication with the client if something mischievous is happening or if the request rate is being crossed.

What would be the best strategy to handle data synchronization between a hybridized private blockchain and a public Ethereum network? Hyperledger Ares is designed to work with crouching networks itself. So it supports enhanced support for synchronization between multiple networks. Apart from that, considering Hyperledger fabric itself, which is having pluggable models, we can design the system in such a way to trigger with the external system like Ethereum or any other blockchain networks and set up an intercommunication between the networks. And, Hyperledger also supports interchain and interchannel triggering so that the chain code, which is currently being executed, can trigger the dedicated chain code, which is responsible for communicating with the rest of the blockchain networks. So by this means, we can enable cross-chain communication and hyperledger can facilitate this by providing a framework for inter-blockchain communication.

Can you outline a strategy for implementing the repository pattern in an application that communicates with both MongoDB and PostgreSQL? Yes, usually, when we're designing any back-end application or any other application, we're just communicating with the repository. A repository, in the sense, is nothing but a database where we store our objects or any other application-related data for a longer run. Let's consider an example of Go. In Go or any other object-oriented supporting language, we can define a repository layer in terms of an interface where a repository will be providing a list of functionalities that are either to read data or to write data or update data or delete data, like considering very basic CRUD operations that I'm mentioning. So, now the application layer or the core layer can directly call any of the implementations of this interface without even having the knowledge of whatever is implemented under the hood. Let's say, in our case, we can write a PostgreSQL client to implement this interface and provide these 4 IDs of CRUD operations. And, internally, we can write the specific PostgreSQL queries to talk to the database, particular data. Similarly, instead of using PostgreSQL, we can come up with a MongoDB client and just implement for these 4 functionalities that we defined in the interfaces. And, under the hood, we can write the MongoDB-specific client to talk with the MongoDB server and provide back the functionalities. Here, we have to look into very important thing that is modeling the data. Let's say I'm writing a repository layer for any one of the database layers. First, I will have to define the models. Let's say, I'm writing it for a book, then I will have to define the model for books, like whatever the structure that has to be passed when we try to create it, and what will the structure when we try to read it, and similarly for update and delete. So, we'll have to define this. However, in the internal implementation, we should have to take care of transforming this generic modeled object into our database-specific format. In most of the time, it would be similar only, but, however, with respect to database relational database, we have to take care of considering the per-specific database schema table schema. So, this gives us a freedom the application layer to choose any of the database that we want to use at the runtime, irrespective of the under the hood implementation. So, this repository pattern would act as a layer after the routing and core of the application. We might have routing in case of back-end applications, which provides APIs for the front end. For any other applications, let's say, which are not networked applications, they can now only have the core and repository layers. These core layers sometimes are also called as business layers.

What are the key considerations when designing microservices that interact with dockerized blockchain nodes? Whenever we deploy blockchain applications in a dockerized environment, that is one of the most user-friendly ways of deploying blockchain applications, because a single blockchain network consists of many nodes, especially when we are trying something in our local environment or even for production. Like we will be going for the containerized environment for its robustness that it provides. Some of the things we have to consider while designing a microservice to interact with this blockchain containerized environment are the network setup that we make to enable communication between these two, the microservices architecture and blockchain networks. We have to make sure we set up a common network or, if the containers are established in two different networks, we have to provide proxy layers in between to provide common domain names. First, we have to allow communication between the containers by setting up proper network settings and firewalls. When we talk between docker containers in the same network, we usually use container names for communication. However, when these communications happen, if we have enabled TLS, we have to make sure that whatever certificates we have generated for the node's identity cope with the container names, because they should represent the domain name. We will have to rename the domain-specific or the certificate should have entries of the local domain. Even when communication inside the container takes place using IP addresses and ports, we will have to use container names when a container talks to another container in the network. Apart from network concepts, we have to take care of orchestration, if we go for a container orchestration environment like Kubernetes. We should take care of parameters like clustering, where two containers residing in two clusters have to take a few more steps to talk to an external system like HAProxy to communicate with each other. We will have to take care of these things. And absolutely, we should have retry mechanisms whenever communication is set up between the two systems. This is because it is very possible that the containers will go down due to application failures or resource constraints. However, the orchestration tools will bring back those containers to maintain the network up and running. So every communication between the two containers should always have retry mechanisms to keep the system robust and communication intact.

What criteria would you use to choose between a RESTful API and RabbitMQ implementation for a blockchain application? Let's first look into the major features and differences between the RESTful API and RabbitMQ implementation. RESTful API is where the communication between the client and the server happens in a more synchronous manner. It is stateless and a predefined set of request methods and response status are already defined in REST. Whereas in RabbitMQ, it is more suited to an event-driven architecture, where RabbitMQ majorly acts as a message broker between multiple systems. Usually REST communication happens between two individual entities where the client requests the server and it goes back to the response. However, we can maintain load balancers in between to set up the communication between multiple server setups to answer a single client. However, in RabbitMQ, the scenario is completely different, where we have a common buffer-like channel where the requester pushes the data event into it. And at the other end, the listeners pick one from the RabbitMQ queue and handle them, pushing back the response into one more dedicated queue. So for a blockchain application, it mainly depends on the part of implementation that we are looking into. Let's say if we are looking for a system where blockchain notification is happening, then we can go for RabbitMQ implementation. Let's say our blockchain service or DLT service is on one place and we have clients on another end. Let's say if the operation is a very time-consuming or long-duration operation, then we can go with RabbitMQ, where a client makes a call, pushes an event to the RabbitMQ queue, and waits for the response. That becomes an asynchronous communication, you will not be actively waiting for the response. So the DLT system, the blockchain system will process the request, and once the transaction is executed, endorsed, ordered, and verified, once it goes into the ledger, once it is finalized, then it can send back an event to the RabbitMQ queue, which will be taken by the client and then responded to the client. Till that state, it can just say processing or in process status. That is not the case in RESTful APIs. However, RESTful APIs are suitable for those cases where the processing is not too long. So that, let's say a client makes a request that immediately gets accepted by the system and processed and gets back a response with either success or failure status. So this completely depends on the use case. Most preferably, if the system requires immediate responses or we are pretty quick to respond to the end user, then we have to go with the REST APIs. However, if the system has to be designed in an asynchronous way, where the processing is a time-consuming part, then we will have to go with the RabbitMQ implementation.

An ethereum smart contract function intended to transfer ERC-20 tokens between accounts is failing for some transactions. The error reported is ERC-20 transfer amount exceeds the balance. Based on the solidity code snippet, can you determine why this might be occurring and propose what checks a developer should include to debug this issue. Here the function transfer takes address and value, public returns, whether the successor require balance greater than the value, 20 transfer exceeding balance, require balance of the sender to be greater than and it returns ERC-20, balance is less than, emit transfers return true, yep this is fine, why this might be occurring, okay, as the code simply explains in its first line of implementation itself, here we require the balance of the sender to be greater than the value that he intend to send to the receiver. So here itself we are failing because the sender is having the balance which is less than the amount that he wants to send. So this is why it is happening and as a pre-check what all things I can determine on the client side itself before the request even coming here, absolutely we will have to check this balance of the sender before actually sending this into a smart contract, at the query level itself before we sending the transfer request to the blockchain network, first we will query the balance of the sender, once we query, once we get the response from the network which is having the balance of the sender, we will compare that with the transaction amount that is intended to, if the balance amount the sender is having or the queried amount that of the sender account is less than the amount that you want to send, we will discard the transaction there itself to the users stating that transaction balance is low and hence transaction cannot, account balance is low and hence transaction cannot be done, along with that we can add a few more parameters at the client level itself to verify the receiver details, let us say here we take the address of the receiver, so at the client level step, we can query whether this address is a valid address in the Ethereum network and transaction can be done to this address, that is the pre-check that we can put and to debug this way, to debug this issue, a developer will have to put up in a production system, you should have log lines which clearly state the balance of the user before actually attempting to transfer and yes, these are the things that can be and we have to like a log or the address, the intended address, the sender address and this current balance and its intended value to be transferred, if you log these lines along with other contextual data, then that would help the developer in debugging this, it is also a very good practice to make use of a unique request ID, a request response ID and we have that also logged in, so that and sharing this request response ID even with the requester, so that even requester with that particular unique identifier, he can know or deep dive into what exactly happened and what is the reason for the failure and at what place of code that failed, we can also use a stack trace to know where exactly the failure happened and we can have monitoring tools also to report this error.

During the development of hyperlative fiber chain code in Go, a larger query code snippet is not returned. Returning the access result for certain keys can spot a potential logical issue that might be causing the mismatch in queries. Shim note. Mark stub. Example chain code. Okay. Get state for some key. This key is not equal to retention. Error or failing to get state for key causes the mismatching query result. Okay. We create a mock stub, and then we try to get something out of it by passing a particular key. Here, we call it the sum key. And if the error is not null, there might be many reasons like the collection itself does not exist or there may be Ivo failures, such as communication between the system and the caller fails. And if the red value is nil, that means the key did not exist at all in the cached state database. So we'll return the shim error. However, if everything goes well, even if we read the value from the state database by calling state get state, we are not returning the value here itself. If we observe the print here, we are just printing the value and not returning it. This is one of the major issues. And along with that, in get state, when we are calling get state, we are trying to fetch data from a particular common code. We have to create a complex key or a concatenated key out of the key that we want and the collection that we want to read. So we will have to concatenate example cc and some key together to make a complex key and then make the query to get the expected result.

Hyperledger network supports upgrading the chain code basically by using the chain code version. So, let's go through the process. We have a running Hyperledger Fabric network with an established chain code inside it, however, due to some business requirements or other aspects. Now, we need to upgrade the logic that this chain code is having. First, we will have to prepare the new chain code that we want to deploy. We have to package it like any one of the organizations in the network can package the chain code, and this will have to get uploaded into the chain code, meaning it should get installed in all the peers of different organizations in the network. So, this packaged chain code should be shared with all the organizations, and they will have to install it in their peers with a particular chain code version, which will give a unique identifier for that installed chain code package. Then, we will have to complete the installation, so then we will have to approve this chain code. When we install the chain code, it gives a unique identifier, and when we install it, we can pass a particular version to it. Even while approving, we can give a particular human-readable string, which is called the chain code version, and apart from that, there is one more incremental value, which is called the sequence number, which should be more than the previous chain code. However, here the chain code name would be the same, but the chain code version and the sequence number will be different and will be incremental. So, now once this chain code is installed, all the organizations, at least the minimum number of organizations required to approve this chain code, should trigger the approval of this particular chain code with the updated chain code version and sequence number. And once that is sufficient, then we can commit the new chain code version into the system. Like, trigger a transaction, any one of the organizations can trigger a commit of this new chain code version. So, by that particular transaction, whichever it goes into the block, one this block gets committed in all the peers. By that commitment, the new chain code version will be used. That is, let's say if we send the transaction number 100 as the commit for the new chain code version, then all the peers which commit this 100th transaction will start using the updated chain code version and discard the previous one. Since we are now almost eradicated any downtime or data inconsistency, all the peers at the same point when they commit the transaction number 100 will start using the updated chain code version as it is already pre-installed in them. So, there is no additional boot-up time there because the containers which are having the updated chain code versions are already warmed and ready for execution. However, to increase or change the endorsement policy and the chain code, we do not need to package the new endorsement new chain code at all. Rather, we can just use the existing chain code package itself, where all the organizations' required permissions have to accept the updated endorsement policy. So, this update does

When interacting with machine learning algorithms in a blockchain application for proactive predictive analysis, I consider the following factors. Okay. Let's say we design any blockchain system; we have to first identify and understand that a DLT, the core blockchain system, is a part of the bigger business need. So, in the example of Hyperledger Fabric, a transaction is successful only after commitment, not during endorsement, not even during audit. We can have machine learning or AI-oriented systems running parallelly to our DLT system, our blockchain system. Whenever a particular transaction is committed, we can emit chain code events or custom notifications, which can be read by the block chain system, feeding this machine learning or blockchain or AI system. This will contain enough data, which depends upon the business logic. This should contain the data that is sufficient for the ML model to get trained on and to understand the type of transaction that happened. This is one way of using chain code events. Another way is for the client making a request to the blockchain system to look into the status of the transaction it has submitted. It can watch the status once it submits the ordered transaction to the order asynchronously or synchronously. Once the transaction is committed, this particular client can know the status of it, whether the transaction was submitted and was it committed as valid or invalid, if it's invalid, for what reason? The client has access to that completed transaction. So, now the client can trigger one more transfer which can have this commit status, and along with that, the initial request which was made, the initial transaction request. All this data can be packaged and sent to a ML model for further processing. This considers the communication between the client and the ML model. The way we can do this depends upon the system. A system where the ML model is strictly associated with the DLT network can communicate directly with the DLT network using chain code events. But if we want the ML model to look into something at the client end, with the client applications, we want to decide something and we don't want to look into the whole transactions happening in the network, then we can implement this ML communication at the client or SDK level. Once the transaction is committed, we can feed the same into the ML model for predictive analysis.

what method would you use to manage and orchestrate multiple Docker containers running blockchain nodes in different environments? Okay, multiple Docker containers running blockchain nodes in different environments. What method would you use to manage them? Docker containers have already helped developers and the operations team, or combinedly the DevOps team, in many ways in managing the application lifecycle at a production scale. And additional tools, like containers and container orchestration tools, like Kubernetes, have even helped us more in utilizing these container environments in a very robust manner. Again, we can define our own development environment and have container orchestration tools to look into these different containers running at various networks, as I mentioned in one of the previous while answering one of the previous questions. When these node containers are running at different environments in terms of containers, it's like running in different clusters, even though the exact hardware where these containers are running at different geographical locations. They can still be configured to run in a single cluster, so that the network physical network complexities that we see are abstracted to the lower level. And the containers will talk to them as if they are in a common network. However, they are virtually in a common network, but not physically. Apart from this, using container orchestration tools like Kubernetes, we have cloud-provided containerization environments, like Amazon container management tools, which also provide orchestration tools, like Amazon Kubernetes tools, which also provide the next set of functionalities. We can provide the number of nodes to be running and the minimum number of nodes to be maintained, and how we scale up in case of increased load. This cloud environment provides these functionalities too, so this will help us to maintain a robust system. We can maintain multiple containers to maintain multiple nodes as multiple nodes help us in increasing the robustness by spinning up sufficient numbers of containers to make a fail-safe scenario. And modern tools, container organization tools, have come up with the logic like reverse proxies, HA proxies, to set up the communication between the containers seamlessly. Where they take care of all the virtual networking, and along with that, they also provide capabilities to provide security rules over the containers. We can block the communication between some containers if we want to, and along with that, we can maintain them under a common subnet, where the communication between them happens at the level three of networking. Hence, we don't see that much of a network latency, and it helps us to create a robust and yes fast system also.