DEV Community: Vanshika Srivastava

How to build your first zkApp with Mina Protocol

Vanshika Srivastava — Thu, 27 Jun 2024 13:52:45 +0000

Today we'll be doing a deep dive to understand to zkApps and how you can build one using Mina Protocol.

What is a zkApp ?

A zkApp is an app which is based on zero knowledge proofs. In the context of Mina, these zkApps utilise zk-SNARKs and can perform complex off-chain computations with a fixed fee to verify the zero knowledge proof on the chain.

Mina's recursive zero-knowledge proofs, which are composable, let developers reuse proofs of already verified information across different blockchains and applications. This approach reduces verification costs, supports composable builds, and enhances privacy for both user and company data. Moreover, various zkBridges are in development to allow decentralized applications from other blockchains to benefit from Mina's features.

The best part about zkApps is that you can make these apps using typescript. Simply a zkApp consists of smart contract and a UI (frontend).

Img Source : Mina Protocol

Understanding o1js for Writing zk Smart Contracts

o1js is a versatile zk framework that provides the tools necessary to create zero-knowledge proofs. It allows you to develop various zk programs using a comprehensive set of built-in provable operations, such as basic arithmetic, hashing, signatures, boolean operations, comparisons, and more. The o1js framework is designed to facilitate the creation of zkApps on Mina—smart contracts that run client-side and handle private inputs.

Recursion
Kimchi, the custom proof system that powers o1js, enables the construction of infinite recursive proofs for circuits through its integration with the Pickles recursive system. Mina Protocol is unique in offering infinite recursion capabilities.

Recursion is an immensely powerful tool with numerous applications. For example:

Mina employs linear recursive proofs to compress its blockchain, which continuously grows, into a constant size.
Mina also utilizes "rollup-like" tree-based recursive proofs to compress transactions within blocks down to a constant size in parallel.
An app-specific rollup, such as a Mastermind game, can use linear recursive proofs to advance the application's state machine without needing to sync back to the game.
App-specific rollups can communicate with each other using recursion, similar to how app chains utilize Inter-Blockchain Communication (IBC) in Cosmos or Cross-Chain Virtual Machine (XVM) in parachains to send messages.

I also shared a video over twitter explaining how typescript developers can now start building zkApps. Check it out here

Setting up zkApp CLI to scaffold, write, test, and deploy zkApps (zero knowledge apps) for Mina Protocol

We will start off with dependencies :

NodeJS v18 and later
NPM v10 and later
git v2 and later

If you have a later version of a dependency, install the required version using the package manager for your system:

MacOs Homebrew
Windows Chocolatey
Linux (apt, yum, and others)

As recommended by the Node.js project, you might need to install a recent Node.js version using NodeSource binary distributions: Debian, rpm.

To verify your installed versions of dependencies, use node -v, npm -v, and git -v.

Usage
To see usage information for all of the zkApp CLI commands:

$ zk --help

Install the zkApp CLI

To install the latest version:

npm install -g zkapp-cli

To confirm successful installation:

$ zk --version

Building zkApps using `zkapp-cli`

1.Create a project

$ zk project <project-name>

o1js is automatically installed when you generate a project using the zkApp CLI.

To proceed without an accompanying UI project, select none when prompted.

See Option B: Start your own project.

To create a UI, select a framework and follow the prompts.

2.Implementing test code for the project

When you use the zkApp CLI to create a project, it comes with built-in tests and examples.

o1js provides an array of 10 test accounts for the simulated LocalBlockchain instance, which are used to pay fees and sign transactions. These can be accessed via `Local.testAccounts.

The example utilizes the public/private key pairs of two of these accounts, named as follows (though you can rename them as needed):

deployerAccount: Deploys the smart contract
senderAccount: Pays transaction fees
Deploy the smart contract to the simulated LocalBlockchain instance, which acts as a test network.

Refer to the localDeploy function,for example, in the [Add.test.ts](https://github.com/o1-labs/zkapp-cli/blob/main/templates/project-ts/src/Add.test.ts#L38-L46) example file for details.

3. Adding the implementation for smart contract

Start experimenting with iterative development to build and test one method at a time. Add functionality to the smart contract by implementing a @method.

Build the smart contract:

npm run build

Invoke the @method you added or use new functionality in the test file.

To test zkApp locally you can npm run test in your project's root repository which will allow you to run and test application on a simulated local blockchain.

4. Test with Lightnet
Use Lightnet to accurately test your zkApp in a Mina blockchain-like environment.

Start Lightnet with the following command:

zk lightnet start
By default, this launches a single node, which should meet most testing needs.

Check the status of your local blockchain:

zk lightnet status
Communicate with the Mina Accounts-Manager service to retrieve account details. This service is available at:

http://localhost:8181/

Use the HTTP endpoints to acquire, release, list, lock, and unlock accounts.

Configure your zkApp to interact with the Lightnet blockchain using the endpoints provided by the zk lightnet status command.

Set the Mina GraphQL API URL for deployment to:

http://localhost:8080/graphql

Set the transaction fee for deployment (in MINA) to 0.1

5. Deploy your zkApp to Lightnet:
zk deploy

You can check out the example application here.

Here are necessary links that will help you better guide and build zkApps.

You can join Mina's discord channel to learn more and connect with Mina developers as well as the community.

SubQuery Network : the Future of Decentralized Web3 Infrastructure

Vanshika Srivastava — Wed, 06 Mar 2024 17:56:50 +0000

TL ; DR

Blockchain technology is rapidly advancing, processing numerous transactions every second. However, unlike traditional databases, blockchain data is not easily searchable due to its ledger structure. To query the blockchain, data must be indexed. This data is extremely valuable for developers to track activities happening on-chain. The Subquery network offers decentralized middleware services like indexers and RPC providers, supporting over 150 ecosystems across the web3 ecosystem. It provides decentralized APIs to dApp developers, allowing data aggregation across multiple chains within a single project.

But first, what is data indexing ?

In the context of databases, the concept of data indexing is well-known.However, in the web3 ecosystem, it has a slightly different objective. Essentially, indexing involves organizing, structuring, and formatting data which includes contracts, events, transactions residing on various blockchain networks such as Ethereum, etc. As a developer, one can streamline the data retrieval from these various chains and also understand the user behavior and interaction on-chain. Indexers are tools that help you to query the data stored on blockchain and can index smart contract events based on certain conditional statements provided by developers.

Due to blockchain’s decentralized nature, the data is spread across thousands of nodes which can make it difficult to aggregate and utilize as per the needs. It would be really difficult for anyone to fetch data around a specific wallet address, to be able to run an efficient query that requires indexers. It's important to highlight this because, for example, accessing details like the first transaction of wallet "XYZ" with a token "TKN" or the largest transaction in the smart contract "SC" is impossible unless the smart contract explicitly stores this data.

A truly decentralized set of indexers will perform better as the nodes are distributed and will keep the system away from the DDOS attack. Secondly, decentralized indexers are not reliant on a single server so there is no single point of failure if one server goes down.

With that being mentioned, let me introduce you to SubQuery Network, a true decentralized infrastructure provider with an open-source data indexer that is fast, flexible and supports to 100+ ecosystems including Osmosis, Cosmos, Ethereum, Polygon, Polkadot, Algorand,etc.

A developer introduction to SubQuery Network

Decentralised Data Indexers provided by SubQuery offer fast, reliable, and customized APIs for web3 projects. By providing an indexed data layer, one can easily retrieve data and enable intuitive user experiences across the dApp. The process of building, testing, deploying, and running these Data Indexers is simplified, making dApp development a breeze with SubQuery.

The SubQuery Network can accommodate any SubQuery Project from any Layer 1 network, whether it's within Polkadot or not. Its design and construction are inherently multi-chain, which allows for indexing of projects from various networks side by side.

Key Features of the SubQuery’s Comprehensive Multi-chain Indexer

EVM, WASM, and more: The indexer supports a wide range of smart contract execution languages, providing users with maximum flexibility.
Write once, run anywhere: With the capacity to index multiple networks into a single database, it simplifies and streamlines operations.
Absolute performance: The indexer boasts rapid syncing and indexing optimizations, ensuring superior performance at all times.
The power of GraphQL: Supporting filtering, subscriptions, and aggregation, the indexer is equipped with all the features necessary for any project.
Faster reindexing: Thanks to automated historical state tracking, partial data can be reindexed more quickly, saving valuable time.
Lightweight and portable: The indexer doesn't require an expensive archive and can connect directly to any RPC, making it a cost-effective and efficient solution.

The SubQuery network has four primary participants.

Consumers: These are the entities that request specific data for their decentralized applications (dApps) or tools from the SubQuery Network. For each data request, they pay a predetermined amount of SQT. For more information, refer to the section on Consumers.
RPC Providers: Also known as Node Operators, RPC Providers operate the SubQuery Data Node optimized for performance. They are compensated in SQT for offering reliable, affordable, and scalable RPC services to the network. For more insights, look into the RPC Providers section.
Data Indexers: As Node Operators, Data Indexers manage and maintain high-quality SubQuery projects within their infrastructure. This includes running both the indexer and query service. They receive SQT rewards for the data requests they cater to. Further details are available in the Data Indexers section.
Delegators: Delegators participate in the network by supporting their preferred Node Operators. They earn rewards based on the work performed by these Node Operators. More information can be found in the Delegators section.

Building your first project with SubQuery :

Now its time to Build ⚒️ We will try to spin up necessary dependencies for our SubQuery project.

Prerequisities :

NodeJS: You will need a recent version of NodeJS installed, preferably the LTS version.

Docker: This tutorial will utilize Docker for running a local variant of SubQuery's node.

Install the SubQuery CLI:

Install SubQuery CLI globally on your terminal by using NPM.

# npm installation
npm install -g @subq/cli

# Testing installation with command argument
subql --help

Initialising a new SubQuery project :

Run the following command inside the directory that you want to create a SubQuery project in:

subql init

Once you have successfully initialised the package, you will be asked certain questions around the project.

Project name: A project name for your SubQuery project.
Network family: The layer-1 blockchain network family that this SubQuery project will index. Use the arrow keys to select from the available options (scroll down as there are multiple pages).
Network: The specific network that this SubQuery project will index. Use the arrow keys to select from the available options (scroll down as there are multiple pages).
Template project: Select a SubQuery template project that will provide a starting point in the development. For some networks we provide multiple examples.
RPC endpoint: Provide an HTTP or websocket URL to a running RPC endpoint, which will be used by default for this project. You can use public endpoints for different networks, your own private dedicated node, or just use the default endpoint. This RPC node must have the entire state of the data that you wish to index, so we recommend an archive node.
Git repository: Provide a Git URL to a repo that this SubQuery project will be hosted in.
Authors: Enter the owner of this SubQuery project here (e.g. your name!) or accept the provided default.
Description: Provide a short paragraph about your project that describes what data it contains and what users can do with it, or accept the provided default.
Version: Enter a custom version number or use the default (1.0.0).
License: Provide the software license for this project or accept the default (MIT).

subql init
Project name [subql-starter]: demo-subquery
? Select a network family Ethereum
? Select a network Ethereum
? Select a template project ethereum-starter     Starter project for Ethereum networks
RPC endpoint: [https://eth.api.onfinality.io/public]:
Git repository [https://github.com/subquery/ethereum-subql-starter]: [https://github.com](https://github.com/jamesbayly/test-subquery-project)/vanshika-srivastava/demo-subquery
Description [This project can be use as a starting po...]: A demo project for showcasing subquery
Version [0.0.1]:
License [MIT]:
Preparing project... done
demo-subquery is ready

Once initialised, your directory structure would look something like this :

demo-subquery
 L .github
 L abis
 L docker
 L src
    L mappings
      L mappingHandlers.ts
    L test
    L index.ts
 L .gitignore
 L LICENSE
 L [README.md](http://readme.md/)
 L docker-compose.yml
 L package.json
 L project.ts
 L schema.graphql
 L tsconfig.json

Now, let run the following command to install the right dependencies inside the directory we just had set up. I am using npm, but if you like you can use yarn as well.

npm

cd demo-subquery
npm install

To have more reference of other command line arguments supported by SubQuery you can simply checkout this section of docs.

Post initialisation modifications :

There are 3 important files that needs to be modified. These are:

The GraphQL Schema in schema.graphql.
The Project Manifest in project.ts.
The Mapping functions in src/mappings/ directory.

Based on the chain network that you would have opted, you can checkout the specific guide related to setting up the project. Here is the quickstart guide for the chains.

💡 You can generate a project from a JSON ABIs to save you time when creating your project in EVM chains. Scaffolding saves time during SubQuery project creation by automatically generating typescript facades for EVM transactions, logs, and types. Please see more here on EVM Project Scaffolding

What’s next for developers ?

SubQuery offers a managed service solution that allows you to effortlessly publish your project. You can deploy your new project to the SubQuery Managed Service and use the SubQuery Explorer for querying. For a comprehensive guide on how to publish your new project to SubQuery Projects, refer to the provided instructions.
For an in-depth understanding of the developer documentation, refer to the Build section. Here, you'll learn more about the three essential files: the manifest file, the GraphQL schema, and the mappings file.
SubQuery allows you to run a local SubQuery node which includes indexer and query service along with the Managed service. You can run this service using Docker or running individual components using NodeJS.

You can checkout some of the advance features of SubQuery Network here :

Multi-chain indexing support - SubQuery allows you to index data from across different layer-1 networks into the same database, this allows you to query a single endpoint to get data for all supported networks.
Dynamic Data Sources - When you want to index factory contracts, for example on a DEX or generative NFT project.
GraphQL Subscriptions - Build more reactive front end applications that subscribe to changes in your SubQuery project.

If you are someone using The Graph and would like to migrate to SubQuery, here is how you can migrate your project. You can also read more on how SubQuery is different compared to The Graph.

SubQuery's Future Roadmap: Enhancing RPC Performance and Democratizing Access

SubQuery has already achieved significant breakthroughs in decentralized data indexing. The focus now shifts to enhancing the performance of RPCs with the SubQuery Data Node and transitioning RPC access with SubQuery's Sharded Data Nodes. These initiatives are expected to unlock the next level of performance improvements in the web3 sphere.

Historically, the performance of data indexers and numerous other applications has been confined by the limitations of RPC endpoints. Developers have primarily concentrated on developing nodes that ensure efficient validation, thereby safeguarding the network. As a result, RPCs are not optimized for querying and impose high operational costs.

The introduction of L2 chains increases transaction speed, but their limited querying capabilities make data retrieval inefficient. In Q2 2024, SubQuery plans to launch the Data Node, a heavily modified RPC node that is optimized for querying. This includes optimized endpoints like eth_getLog and the ability to filter transactions in a single API call. The Data Node will be open-source, inviting contributions, extensions, or forks from the community. Initially, it will support leading layer-2s and other EVM networks, and it will be optimized to function on the SubQuery Network in a decentralized manner.

By the end of 2024, SubQuery aims to democratize RPCs by introducing the Sharded Data Node. This will make RPCs more affordable to run and operate for node providers.

You can join SubQuery’s community here to stay updated with everything that’s being worked on by SubQuery team. If you are developer like me and would like to contribute to the project itself, you can checkout the contribution guide here .

Understanding Power of Horizen EON's Stateful Model: User Experience in Account-Based Transactions

Vanshika Srivastava — Wed, 28 Feb 2024 17:49:21 +0000

TL;DR

In blockchain, we have two major accounting models, UTXO which views the state as a flow of assets between addresses while in the account-based model, the state changes with each transaction adjusting account balances accordingly. Horizen’s EON is a powerful EVM (Ethereum Virtual Machine) sidechain that is able to send and receive $ZEN via the Cross Chain Transfer Protocol using zero knowledge cryptography. Some of the many advantages of Horizen EON is to improve user experience,reduce development complexities and provide a set of tools and ecosystem to integrate with different dApps and deploy smart contracts on top of the network.

Introduction

Blockchain space has been growing faster than we anticipated. The infrastructure for Web3 applications must be enhanced to manage a greater volume of transactions, improve performance, and maintain privacy. The user experience is the highlight of any product, users want to have full ownership of every function as well as their funds.

In order to support this demand for true decentralization, enhanced security and transaction efficiency, Horizen has created a new paradigm for developers and end-users.

Horizen is an interoperable blockchain ecosystem that prioritizes security and the ability to scale. At its core, it employs the zero-knowledge-proof protocol, specifically zk-SNARKs, to secure communications and ensure that inter-chain conversations remain safe.

To defend against potential blockchain attacks like the 51% attack, Horizen has implemented a robust set of security measures. This includes a carefully designed consensus mechanism, the notarization of blocks across multiple chains, and TLS end-to-end encryption to shield data from prying eyes.

It also uses the largest and most decentralized multi-tiered node network in the industry, ensuring reliability and maintaining a distributed ecosystem.

Horizen is compatible with the Ethereum Virtual Machine (EVM) via Horizen EON, which is a sidechain and is a smart contract platform for developers to support the blockchain trilemma for decentralization, scalability and privacy and uses Horizen’s massive computational power.

Throughout this article, we will explore how the EON sidechain from Horizen supports an account-based model for web3 users and examine the broader implications this has on transactions and decentralized applications.

To learn more on Horizen’s architecture, you can check out the official docs here.

Evolution of blockchain models

Blockchain is a distributed ledger of transactions, fully immutable and always available. Now, to prove the source of transaction and the balances of cryptocurrency a user owns on a network, we have two models of keeping a record for transactions: the Unspent Transaction Output (UTXO) model and the account-based model. From a blockchain architecture perspective, they play a role in maintaining the accurate “ledger” of transactions while ensuring privacy.

To give a brief of both models, the UTXO model is simple and privacy-focused, treating each coin as a unique transaction output. Bitcoin, for instance, uses the UTXO model. Each transaction creates a new set of UTXOs, and the ownership of these UTXOs is what represents a user's cryptocurrency balance. Now, once a transaction is completed on the blockchain, the tokens or funds that were spent get removed from the UTXO database. UTXOs can be considered individual chunks of funds that can be combined and broken down to process transactions.

In the account-based model, which is followed by Ethereum, the assets are represented as balances with accounts. You can think of this model as a simple banking process where a bank being a ledger, records the transfer of the assets or funds as debit and credit in the respective user accounts. In other words, account-based blockchains would technically not track any of the tokens you own but notify changes on the accounts or wallet addresses. Therefore, the user's identity, represented by their unique account address, becomes integral to the transaction process.

Let’s take a look at how the stateful architecture of an account-based model impacts the overall user experience.

Stateful model and potential of account-based blockchains

Before we jump into the stateful architecture and state mechanisms, it's essential to understand the basic structure of a blockchain. This structure is adhered to regardless of whether the blockchain is based on UTXO or accounts.

Transactions are disseminated across the network:

A new block is generated
Transactions are permanently recorded on the chain
Smart Contracts are the backbone of the blockchain systems.

The stateful model connects with the “memory” of smart contracts to remember information about its ‘previous interactions’ on the blockchain.

For instance, Ethereum uses a stateful architecture in which all the miners on the blockchain network update their copy of the network each time a new transaction occurs on the blockchain.

Comparatively, in the UTXO model of Bitcoin, the smart contracts are inherently stateless. This is why a UTXO is destroyed once it has been spent.

Smart contracts, owing to their stateful nature, are capable of managing interactions with more programmable logic than their stateless counterparts. They can also store and update chain values.

Platforms like Horizen, thanks to the account-based model, can build applications effectively. Its public proof-of-stake sidechain, EON, is fully compatible with EVM smart contracts. This compatibility aids in the development and deployment of decentralized apps on Horizen while maximizing the advantages of the Ethereum ecosystem.

The stateful model introduces two distinct account types: Externally Owned Accounts (EOAs) and Contract Accounts.

EOAs are created when a user initiates their wallet, whereas Contract Accounts are established when a user deploys a smart contract. In later sections, we will dive deeper into these and understand how they impact the overall user experience on stateful blockchains.

Blockchain as a “state” machine

In a blockchain context, the term "state" refers to a snapshot of all information on the blockchain at a particular point in time. This includes the current status of all accounts and transactions in the network. It's a dynamic concept, continuously updated with each new block added to the blockchain, ensuring it reflects the latest transactions and account balances.

Now, let's discuss the difference in how the UTXO and the account-based models handle state.

The UTXO model, used by Bitcoin, captures the state as an set of Unspent Transaction Outputs, which are the outputs of past transactions that have not been spent. Each transaction modifies the state by consuming some UTXOs and producing new ones. The state in the UTXO model is thus a flow of assets between addresses, represented as a directed acyclic graph (DAG).

On the other hand, the account-based model, used by Ethereum, reflects the state as the current balances of all accounts on the network. When a transaction occurs, the state changes, with the sender's account balance decreasing and the receiver's account balance increasing. The state in the account-based model is essentially a snapshot of all account balances at a given moment, maintained as a database of network states.

Future of account based models - EOAs and Contract Accounts

Externally Owned Accounts (EOAs) are created when a user initiates their wallet in the Ethereum network. EOAs are directly controlled by private keys and primarily serve the purpose of initiating transactions. They offer users full control over their assets, as they can freely transfer funds to other accounts or interact with Contract Accounts.

The Ethereum Virtual Machine (EVM) features a BALANCE operation, which enables us to easily look up an address's balance inside the code running on the EVM. This is a much simpler process than adding all unspent transaction outputs that list a particular address as their recipient.

In addition to the balance, each Ethereum address also includes a nonce. The nonce is a count of all transactions sent from that specific address. This factor is pivotal in differentiating the account-based and UTXO models, where such a count is not maintained. The nonce provides a sequence number for transactions, ensuring their correct order and preventing double-spending and replay attacks.

On the other hand, Contract Accounts are established when a user deploys a smart contract on the Ethereum network. Unlike EOAs, Contract Accounts are governed by their contract code and can only perform actions when triggered by an EOA. They hold both the contract code and its associated data.
The balances, storage, and code space within these accounts are the foundation for efficient and versatile transactions within the stateful model.

A contract account can preserve the address of another contract with which it needs to interact. As this address is stored, it can be modified through transactions. Thus, it's feasible to upgrade a system by launching new contracts and executing a transaction to update references to the new addresses. This process, often called smart contract upgradeability, can be somewhat complex.

User Experience for account-based model vs UTXO

For any user, transaction fees are the starting point to compare the user experience. The method of calculating transaction fees under the account-based model differs significantly from that under the UTXO model. Instead of imposing fees for data storage, the account-based model charges based on the computational resources necessary for processing and validating the transaction.

This approach is facilitated by global state tracking, a comprehensive database detailing all accounts, keys, contract codes, and balances across the network. Having this complete perspective allows the computational expenses associated with state transitions to form the basis for fee calculation.
In contrast, UTXO-based systems can only access the overall network state's local transaction inputs and outputs.

The essential components of accounts on Ethereum include:

Balance: The quantity of ETH held by the account.
Nonce: A counter indicating the number of confirmed transactions.
Storage: The storage space occupied by the smart contract code.
Code: This applies exclusively to contract accounts.

In essence, each account undergoes direct value and information transfers during state transitions, which dynamically affects the status of the network.

As a developer, another reason why choosing an account-based model chain, such as using Horizen’s EON sidechain, would make more sense is because of the underlying tech of how Ethereum uses a Turing complete programming language and allows the arbitrary logic added to smart contracts for more flexibility as well as simplicity to offer decentralized applications serving custom purpose.

In contrast to the UTXO model, each transaction in the account model requires just a single reference and signature, resulting in only one output. This leads to considerable space savings, a critical factor for a large and complex blockchain like Ethereum.

To sum it up, the stateful architecture eliminates the complexities of handling individual transaction outputs and calculating "change," making the transaction process more intuitive and user-friendly. The account-based model is pivotal in EON's blockchain architecture with its nuanced account types - Externally Owned Accounts and Contract Accounts.

With the support of an account-based model and Horizen’s largest node network for a decentralized and secure experience across the ecosystem, we can truly say that the future of web3 is going to be simplified without compromising on blockchain trilemma and developers can opt for a modular settlement layer with EVM compatible sidechain EON for a seamless experience.

Checkout some of the developer examples in the official documentation. Join the Horizen’s community on discord to start learning more about EON sidechain and building with the best infrastructure out there.

Getting started with DevSecOps

Vanshika Srivastava — Tue, 09 Aug 2022 15:00:16 +0000

You might have heard a lot about DevOps, but what do you know about DevsecOps ?

Well in this blog, I am going to introduce this term and why we need to focus on DevSecOps as a key function.

What is DevSecOps?

DevSecOps stands for Developer, Security and Operations. DevSecOps can be taken as DevOps process but with a security layer.

If we go by looking at the traditional DevOps model - the security process is almost absent but usually executed post-deployment which is not a very good idea for any kind of tool/application or project. DevOps revolves around three pillars - People, Product and Processes (as quoted by - Donavan Brown) but when we talk about DevSecOps, we apply security techniques to all these three components.

“The purpose and intent of DevSecOps is to build on the mindset that everyone is responsible for security with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required,” describes Shannon Lietz, co-author of the “DevSecOps Manifesto.”

DevSecOps is different from DevOps in the following ways -

Continuous Integration, delivery and deployment to make sure security testing is regular and automated before the application is pushed to production.
Application built like microservice
Infrastructure as Code - planning, designing, implementing and managing app infrastructure through code

Features of introducing DevSecOps-

Observability
Traceability
Compliance
Confidence

Following the Shift Left Trend :

The earlier you run the security,
the better for your team, product and costs.
You don’t want your developers to work again
on the code base and other issues post-deployment.
This means, the engineers work on
security issues parallelly to working on the product.

Some tips that can make your security operations better when your application is under development -

Make security part of backlog or sprint activity
Assume breaches - progressively expose them to engineering teams so that vulnerabilities can be identified and fixed.

DevSecOps practices reduce the time to patch vulnerabilities and free up security teams to focus on priority work. As a process, they also ensure and simplify compliance, saving application development projects from having to be retrofitted for security.

There’s no doubt that DevSecOps revolutionizes the way organizations handle security for applications. However, due to a variety of reasons—such as a lack of awareness of what DevSecOps is, there might be a shift in interests.

What’s next ?

After exploring DevOps, I am working on learning more about DevSecOps. Here is an open source tool for the same - BoxyHQ

Find Github : github.com/boxyhq
Join the BoxyHQ Discord Community here

Breaking into Tech from a non-technical background 💪

Vanshika Srivastava — Sat, 06 Aug 2022 12:30:09 +0000

Hello amazing community folks!!! I'm so glad I'm finally deciding on writing blog posts and my first one had to be about my journey in tech field.

The first time I felt I should go in Tech :

If you ask me when did I get interested or felt like getting involved in tech, I wouldn't have a precise answer to that.
Tech and development came to me very naturally, more of like hobby.

I remember the days from teenage hood, when computer science was part of school syllabus, I enjoyed helping my mates when we would build simple websites on HTML.(I know that HTML is not a programming language, pls don't start a comment thread over that haha). All I wanted to do was explore.

The bottom line of stepping in Tech :

I have always said that the most important part of being in Tech is that you constantly explore, learn, apply and again learn. This is a never ending cycle.
The more you know, the less it is - technology will change, always and faster than you think.

The first time I wrote "hello world" :

I began six years ago, the resources were limited, it took time to figure out a lot of things if you are self taught. I grew up between smartphones being just launched and facebook was still a thing.

`My first "hello world" was in Python.`

YES, thats my first programming language and I believe I am not the only one who did this. I used to borrow books from library on Python and learn things. It was a tedious process and no doubt it paid off. Overtime, I learnt Java, MySQL and database handling with python.

Coding was not a necessity but a choice :

Since I began to learn things, one thing I understood about myself was - I cannot repeat the same set of tasks everyday. This meant, that even though I loved coding, I would still hop off to graphic designing and poetry (hidden talent you may call) to get some mind off from coding.
I loved communicating with people and being very honest - loved extra co-curriculars.

Talking about my education, in my intermediate I chose the stream which people were quite disappointed about.

Any guesses ?

I took Commerce. I felt I had strong desires to learn how business and management works but my love for IT didn't end with this choice. Engineering was something that would have never worked out for me. I knew that, the quench of this expanding horizons in tech wouldn't come by my degree and therefore it's not necessary to go with a conventional choice of subject.

The best or strongest combination I built over years was mix of management and tech. People went from doing engineering and then taking MBA. This thing taught me a lot.

Skills + Knowledge > Degree

Some educational history :

I completed my 12th in 2020, yup the first set of batch who passed during covid and couldn't appear for two of my board exams. Out of which, one was Information Practices subject.
In both my board exams- I have always been below 90%, my college is second tier, and I am doing course in business management field.

Open Source changed my life :

I can't express the importance of Time when covid struck. A lot of people lost opportunities - and I took that period as an opportunity. I jumped in Open Source. I started learning and building in Public. I overcame the fear of speaking in public when there is no script and have to mention Twitter. This twitter community has given me so much.

Open Source is one thing where your background will not matter as long as you know how to use Version Control and have control over one or more than one language.

EVERY SINGLE CONTRIBUTION COUNTS.

My first stepping stone towards an internship :

I started off with making non-code contributions from last year. Parallelly, I explored DevOps and learnt things around Kubernetes and Microservices. My first contribution happened to be in Data on Kubernetes Community. This community is led Bart Farrell. I wrote a blog post based on one of the video and submitted it for review and good response. This boosted my confidence. With continuous contributions within community, the next amazing thing that happened was - I ended up being one of the four foundation interns at DoK Community. Kunal Kushwaha was the program head for that cohort. We learnt alot from collaborations, events and ofcourse about K8s.

I am keeping the rest of the experiences for next time but
one thing I do want to mention out is :

There is no roadmap for breaking in tech.
You can't follow someone's exact path but
what you can do is always reach out to community
and collect as much knowledge as you can.

The objective of doing something related to tech should be more on the side of learning and giving something valuable to people

In the end, I have just gratitude for the amazing community that has supported and motivated me to do better things - consistently .

Do let me know in comments if this blog helped you to get a clarity of thoughts or anything else that you would like to share :)

Until next time😃