Balbix uses specialized AI algorithms to discover and analyze the enterprise attack surface to give a 100x more accurate view of breach risk

Balbix

balbix

BARRIER REEFS

KEELING ISLAND: CORAL FORMATIONS

Let’s talk about queue design. We have a very long book which we would like many people to read. Some can read during their lunch hour, some read on Monday nights, others take it home for the weekend. The book is so long that at any point in time, we have hundreds of people reading it. Readers of our book need to keep track of where they are up to in our book, so they . Some readers read very slow, leaving their bookmark close to the beginning. Other readers give up halfway, leaving theirs in the middle and never coming back to it. keep track of their location by putting a bookmark in the book To make matters even worse, we are . Nobody can actually finish this book. adding pages to this book every day Eventually our book fills up with bookmarks, until finally one day it is too heavy to carry and nobody can read it any more. A very clever person then decided that readers should not be allowed to place bookmarks inside the book, and must instead on their diary. write down the page they are up to This is the design of Apache Kafka, and it is a very resilient design. Readers are often not responsible citizens and often will not clean up after themselves, and the book may be the log of all the important events that happen in our company. The common alternative design for other queues is for the queue service keep track of where readers are up to – this means needing to allocate memory per-reader. Badly behaved readers may repeatedly request new queue sessions and this can overwhelm the queue service. This often isn’t good a good design as we want readers to feel free to read without any risk to the queue. Apache Kafka Kafka is designed around a stream of events, such as: 1001. ‘ ’ has travel deal ‘ ’ 1002. ‘ ’ has his subscription preference to ‘ ’1003. ‘ ’ has using ‘ ’1004. ‘ ’ has travel deal ‘ ’1005. ‘ ’ has using ‘ ’1006. ‘ ’ has deal ‘ ’ tim purchased fiji tim updated daily sam logged in iphone sam opened bali sam logged in desktop web sam purchased bali Kafka event readers keep track of the ID in the stream which they have read up to, meaning that the event server does not need to keep track of them. This allows the Kafka event server to maintain predictable memory use, even with many poorly behaved readers. Kafka sounds great, why Redis Streams? Kafka is an excellent choice for storing a stream of events, and it designed for high scale. Kafka takes on extra complexity in order to achieve this scale. Provisioning and managing a Kafka setup does need an understanding of some complex concepts. For smaller projects, a simpler and smaller system can be a better choice. Although we all like to solve Google-scale problems, this is very rarely needed. Redis is one of the most common choices for a simple, usually non-persistent data store. It has great library support across all popular programming languages, and is well understood by most developers. It is an excellent example of trading off strong distributed resiliency for simplicity. Redis now supports a simpler version of the Kafka event stream concept, making the architectural concept easily and inexpensively accessible to everyone. To get started with this Redis Streams, I will introduce two new commands that are now in the ‘unstable’ branch of Redis. To follow along with this example, you can create an online Redis instance for free in about 2 minutes. You can also pull the ‘unstable’ branch of Redis from . here here Writing to a Redis Stream XADD stream_name * key1 value1 key2 value2 (etc) XADD allows us to write a stream of events. Let’s create a stream of events reflecting the example above. We will name our stream ‘events’. XADD events * user tim action purchase item travel:fijiXADD events * user tim action preferences subscription dailyXADD events * user sam action login platform iPhoneXADD events * user sam action visit item travel:baliXADD events * user sam action login platform “desktop web”XADD events * user sam action purchase item travel:bali The ‘*’ is used to separate optional parameters from the set of key values. This will write all these actions onto the ‘events’ steam. Reading from a Redis Stream XREAD COUNT 2 STREAMS events item-id XREAD lets us read items from this queue. Let’s read two items at a time: demo.wiftycloud.com:6379> XREAD COUNT 2 STREAMS events 0 “events” 1512991598699–0 “user” “tim” “action” “purchase” “item” “travel:fiji” 1512991602438–0 “user” “tim” “action” “preferences” “subscription” “daily” We are requesting items in the stream ‘events’, starting at the beginning of the list (by passing ‘0’). We requested only 2 items.To get the next two items, instead of beginning at ‘0’, we now begin at the last ID returned by Redis — which in the example above is is ‘1512991602438–0’. > XREAD COUNT 2 streams events 1512991602438–0 “events” 1512991605766-0 “user” “sam” “action” “logon” “platform” “iPhone” 1512991617871-0 “user” “sam” “action” “visit” “item” “travel:bali” Other options are available — BLOCK allows us to have the Redis server wait on the connection until events are available. Between these two commands, XADD, and XREAD, we can very easily construct a queue of business events. Node.js Example Library support for Streams is still not quite ready, however custom commands can currently be used. An example of doing this using ioredis can be found . here TL;DR Kafka is amazing, and Redis Streams is on the way to becoming a great LoFi alternative to Kafka for managing a streams of events.

Kafka & Redis Streams

A Glimpse Into the Past The concept of smart contracts predates the inception of blockchains, having been delineated by Nick Szabo in 1994. The first practical application emerged years later in 2015 with the Ethereum platform. Fundamentally, smart contracts automate contractual obligations and eliminate intermediaries. Smart contracts have found extensive applications in finance, overshadowing their potential to automate processes across various domains. Decentralized Applications (DApps) extend beyond financial tools; they merely scratch the surface. While the DeFi market has soared in complexity and success, other sectors lag behind significantly. Challenges Facing DApps in Non-Financial Sectors: Development complexity and cost Blockchain’s slow performance Lack of robust integration tools (wallets, infrastructure, etc.) Attempts at broader application have made little headway. The State of Gaming in Decentralization CryptoKitties marked the first step towards decentralized gaming, though it was largely controlled by its developers. Axie Infinity, despite its success, faced significant challenges, including a $615 million hack, due to its proprietary blockchain. Moreover, its gameplay mechanics are private, challenging its decentralized nature. Other projects like Gods Unchained and Heroes of Mavia also fall short of full decentralization. The current trend involves separating gameplay from asset ownership (NFTs for characters and items), with gameplay largely centralized. However such projects omit that mere ownership of NFTs does not provide “full control over assets.” Assets only have value thanks to gameplay mechanics, which are 100% under the control of developers. A popular term describing current projects is . GameFi Low decentralization and emphasis on play to earn. Examples: Axie Infinity Illuvium Splinterlands Pixels League of Kingdoms Gods Unchained Heroes of Mavia Seraph Decentralized Games Truly decentralized games are currently few and far between. Existing games can be divided into the following groups: Focus on the Blockchain Component The gameplay consists of a basic set of actions or resembles very basic game mechanics. The characteristic of such projects is that tokenomics are central, with gameplay tacked on top. It’s hard to call these fully-fledged games. Examples include CryptoKitties, DefiKingdoms, Crypto Raiders, and Neon District. Community-Developed Ecosystems The main project develops only basic assets while the community ecosystem develops games for these assets. This sounds cool and could achieve full decentralization. The problem is that games tend to be boring and often have centralized gameplay. This approach could lead to some good games, but any successful project within such an ecosystem is likely to outgrow it and become its own entity (as happened with DOTA evolving from a map for Warcraft 3 into a standalone game). Examples are Aavegotchi and Axie Infinity (planned). SDK for Simplified Game Development This route allows for significantly fewer resources to be spent on blockchain, and in theory, the gameplay should be more refined. This approach is very promising, but there is a risk that all games will look alike and be quite formulaic. Nonetheless, studios that invest efforts in developing an SDK based on their contracts have every chance to make a good game as a “showcase” for their engine (similar to Unreal Tournament from the web2 era). Examples include MUD SDK and Paima Studios SDK. Effort to Combine Forces Creating quality gameplay and laying the foundation for full decentralization. This approach requires prioritizing the creation of a gameplay process where blockchain serves as an advantage rather than a checkbox feature. This direction is the most promising but also the most challenging. Examples are Primodium and Sacra: Falling of Myrd. Why Do We Need Decentralization for Games? To break the current trend, it’s necessary to focus on the question, and convey this to the users. “Why does a game need to be decentralized at all?” The simple answer to this question is the same as “Why is Bitcoin needed?” Real Ownership of Assets True ownership of an asset means control over its value. Only by providing decentralized gameplay can you guarantee real ownership of the asset. Security Open source is not just a whim of crypto maximalists. Only open source allows for a real security audit and identification of vulnerabilities. Moreover, immutable (or DAO-controlled mutable) code guarantees the preservation of assets and the gameplay mechanics that give value to the game’s main assets. Economy Building a complex economy capable of handling significant assets requires unprecedented quality and security of code in the gaming industry. Fortunately, years of DeFi existence have accumulated best practices in this area. For a game built on smart contracts, it’s easy to imagine an economy operating billions. Excluding the influence of third parties, whether intentional or unintentional, ensures confidence in the stability of the in-game economic model. Resistance to Censorship I think almost every gamer has faced being banned for unclear reasons or even denied access to a game altogether. A decentralized game is protected from this as much as the blockchain it runs on is protected. Even in the presence of a centralized company that supports the game’s UI, the original client code will always be available, allowing the game to be launched locally. Community and Governance The openness of the product attracts a genuinely interested community around the project. The ability to contribute and manage key issues through voting creates incredible long-term support. Integration of Real Assets into the Game Economy A game can be seen as a small state. Like any other state, to ensure a stable economy, it can own assets of other states. This is fully relevant for decentralized games. It’s easy to imagine assets locked in a game generating passive income and creating additional value for the project. All of this can be summarized in one word: DeGame. Technical Implementation Currently, various blockchains have their smart contracts, but EVM and Solidity are the de facto industrial standards. It’s not just that 90% of all developments are written in Solidity, but also the infrastructure built around EVM networks. RPC providers, The Graph protocol for the backend part, Dune analytics dashboards, and other tools solve many problems that are difficult to compensate for with other tech stacks. But is it really possible to “squeeze” game logic into Solidity given that the size of contracts is limited to 24KB and the block time in most blockchains does not exceed 2 seconds? Yes, it’s more than feasible. There are many design patterns for writing complex logic, such as The Diamond Standard (EIP-2335) and the use of libraries along with the ERC-7201 standard. These approaches allow us to almost completely bypass the limitation on the size of the smart contract code. The gas limit per transaction imposes serious restrictions on the number of actions a player can take in one go. However, the use of packed data and standard gas optimization methods allow for even complex logic such as pathfinding on terrain and determining lines of sight within a single transaction. Blockchain enables unique gameplay mechanics for multiplayer. In a standard MMO game, solving the problem of lag with 1000+ players online is practically impossible, but here, the mechanism of competition for gas comes into play. Moreover, gas payments can be tied to in-game currency through ERC-4337. This means you can control the online servers with in-game mechanics (pay more in-game currency to participate in a castle siege with other players, for example). At this stage, it’s too early to talk about a fully decentralized game with real-time action gameplay. However, game genres with turn-based gameplay fit perfectly with the concept of block finalization. Essentially, technical limitations encourage the creation of new genre combinations, such as turn-based MMO RPGs. Over time, a specific blockchain will be created to process on-chain actions of players sufficient even for real-time shooters. L2/L3 blockchains, which can now be deployed in minutes through a UI, have proven themselves well in this regard. It’s more than realistic to imagine a situation where a blockchain game can create its own temporary L3 for a specific game session. The Future of DeGame As always, games present a real challenge to the entire IT industry, pushing it towards more efficient solutions. Not only is there a need to develop complex logic on smart contracts, but the blockchain must also be capable of processing a huge number of transactions. Fortunately, there are now many blockchains capable of achieving the necessary throughput. A sufficiently large project could even develop its own blockchain to handle transactions specific to the game. A decentralized server part for the game with its validators and consensus. However, in the early stages, a standard universal blockchain is more than enough for games without real-time action. And as experience shows, it’s better to focus on one thing, whether it’s the game itself or the infrastructure in the form of a fast blockchain. In the future, we will see many projects that implement gameplay on smart contracts and open a new era in the gaming industry. This revolution goes hand in hand with the evolution of all crypto projects, and it’s only a matter of time before the old game development is displaced by new approaches.

Stories, News & Mentions about BALBIX

Balbix’s Stories on HackerNoon