As long as there are computer systems, they will have vulnerabilities and exploits. Keep up to date with us to stay informed and safe.

What keeps cybersecurity professionals up at night? It’s not AI… yet

Digital business and IT company NTT DATA has expanded its partnership with Palo Alto Networks to help enterprises safeguard their digital infrastructures from emerging cybersecurity threats. The collaboration introduces NTT Data’s Managed Extended Detection Response Service (MXDR), which ...

NTT DATA Partners With Palo Alto Networks to Help Keep Digital Infrastructure Safe - Australian Cyber Security Magazine

A heated regulatory landscape, uncertainty over AI use, and how it all ties back to cybersecurity means CISOs have to add privacy to their portfolios.

CISOs' Privacy Responsibilities Keep Growing

Arab News - Saudi Arabia based leading English newspaper in the Middle East. Keep up with the latest breaking news, regional news, politics, and business news.

Saudi Arabia unveils initiatives to enhance financial sector talent

Read Next: 7 Reasons a Financial Advisor Can Grow Your Wealth in 2024

4 Money Rules That Financial Activist Dasha Kennedy Says Keep Her Sane

Keep up to date with the latest personal finance news on Express.co.uk. Find out more about savings, mortgages, loans, credit cards, insurance and more.

NatWest makes one vital £17m warning to anyone spending money abroad

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends.

Сloud Security recent news | page 74 of 74 | Dark Reading

(Bloomberg) -- The German Finance Ministry is sticking to a plan to sell off its entire stake in Commerzbank AG despite UniCredit SpA’s move to buy all the shares offered last week, according to people familiar with the matter. Most Read from BloombergCalifornia’s Anti-Speeding Bill Can ...

German Finance Ministry Plans to Keep Selling Commerzbank Shares

Robinson worked for De Niro between 2008 and 2019 as his executive assistant, and then his vice president of production and finance. However, she quit four years ago after repeated clashes with his girlfriend, film producer Tiffany Chen, and is now suing the actor for “severe emotional distress and reputational harm”.

Robert De Niro denies girlfriend gave him ‘ultimatum’ over assistant in workplace abuse case

A TikToker revealed a genius way to keep your vino fresh: Fasten a plastic sports cap from a water bottle to the mouth of the wine bottle.

People call my easy, frugal wine bottle hack to keep it fresher longer ‘genius’

Keep

keepnetwork

121 Stories To Learn About Data Protection

Distributed computing is a complex field with numerous challenges, and understanding the fallacies associated with it is crucial for building robust and reliable distributed systems. Here are eight fallacies of distributed computing and their significance: Assuming that network connections are always available and reliable can lead to system failures when network outages occur, even when the network outages are transitory. It’s essential to design systems that can gracefully handle network failures through redundancy and fault tolerance mechanisms. The Network Is Reliable: Overestimating the speed of communication between distributed components can result in slow and unresponsive systems. Acknowledging network latency and optimizing for it is vital for delivering efficient user experiences. Latency Is Zero: Believing that network bandwidth is unlimited can lead to overloading the network and causing congestion. Efficient data transmission and bandwidth management are crucial to avoid performance bottlenecks. Bandwidth Is Infinite: Assuming that the network is inherently secure can result in vulnerabilities and data breaches. Implementing strong security measures, including encryption and authentication, is necessary to protect sensitive information in distributed systems. The Network Is Secure: Networks evolve, and assuming a static topology can lead to configuration errors and system instability. Systems should be designed to adapt to changing network conditions and configurations. Topology Doesn’t Change: Believing that a single administrator controls the entire distributed system can lead to coordination issues and conflicts. In reality, distributed systems often involve multiple administrators, and clear governance and coordination mechanisms are needed. There Is One Administrator: Neglecting the cost associated with data transfer can lead to inefficient resource utilization and increased operational expenses. Optimizing data transfer and considering the associated costs are essential for cost-effective distributed computing. Transport Cost Is Zero: Assuming that all network components and nodes have the same characteristics can result in compatibility issues and performance disparities. Systems should be designed to handle heterogeneity and accommodate various types of devices and platforms. The Network Is Homogeneous: Understanding these fallacies is critical because they underscore the challenges and complexities of distributed computing. Failure to account for these fallacies can lead to system failures, security breaches, and increased operational costs. Building reliable, efficient, and secure distributed systems requires a deep understanding of these fallacies and the implementation of appropriate software design and architecture and IT operational strategies to address them. Unreliable Networks In this blog post, we will look at the first fallacy, its impact on microservices architecture and how to circumvent this limitation. Let’s say we’re using spring-boot to write our microservice and it uses MongoDB as the backend, which is deployed as a StatefulSet in Kubernetes. and were running this on EKS. You might also question that it is your cloud provider’s job to give us a reliable network and that we’re paying them for high availability. While the expectation might not be wrong, unfortunately, it doesn’t always work as expected when you rent hardware over the cloud. Let’s say your cloud provider promises 99.99% availability, which is impressive right? No, it ain’t! and I’ll explain how. 99.99% availability could lead to Every one request in 10,000 requests failing Every 10 requests in 1,00,000 requests failing Now, you might say that my system doesn’t get that kind of traffic! Fair enough, but this is availability data of the cloud provider, not your instances of service, which means that if that cloud is getting a billion network requests within its network, 1,00,000 will fail! To make things more complex, you can’t expect them to distribute these failures across all accounts using their hardware; you might get hit by any number of those failures depending on your luck. The question here is, do you want to run a business just on the chance of these outages not hitting you? I hope not! So here’s the fundamental description of the first (and most critical) fallacy of distributed computing. The Impact of Network Failures Let’s take an example of an e-commerce system; we’d usually see a product catalog from the Product Microservice; however, the SKU availability might be fetched from another microservice when building the Product Catalogue response. One could argue, though, that I can replicate the SKU information into the product catalog via Choreography, but for the scope of this example, let’s assume that’s not in place. The product service, therefore, is making a REST API Call to the SKU service. What happens when this call fails? How would you convey to the end user whether the product they are looking at is available or not? Scary stuff, yeah? Well, it is not so scary; since we love to brave ourselves on harder frontiers as engineers, we have a few tricks up our sleeves. Coding for Fault Tolerance and Resilience It’s a topic worthy of a book, perhaps in itself, instead of a blog post. But I’ll try to cover all I can while keeping it simple. Most of what I’m sharing here are experiences gathered over transitioning from Monolith to Microservices for the SaaS business in NimbleWork. And I hope others find it helpful too. Patterns for Transitory Outages The following patterns help circumvent transitory outages or blips as we usually call them. The fundamental underlying assumption is that such outages have a lifetime of a second to two at worst. Retries One of the simplest things to do is to wrap your network calls in a retry logic so that there are multiple tries before the calling service finally gives up. The idea here is that a temporary network snag from the cloud provider wouldn’t last longer than the retries made for fetching data. Microservice libraries and frameworks in almost all common programming languages provide this feature. The retires themselves have to be nuanced or discrete; retrying when you get 400 will not change the output for example until the request signature is changed. Here’s an example of using retries when making REST API calls with Spring WebFlux WebClient. https://gist.github.com/anadimisra/d8b4ab5ca882c65d59c1338c35c803da?embedable=true Here’s a summary of what we’re trying to achieve with this piece of code: Retry a maximum of three times in two seconds Space the time between retries randomly based on the jitter Retry only if the upstream service gives HTTP , or statuses 504 503 502 Log the error and pass it downstream when the maximum attempts are exhausted Wrap an empty response instead for client errors or pass the error from the previous step downstream These retries can help recover from blips or snags that aren’t expected to last long. This can also be a good mechanism if the upstream service we’re calling restarts for whatever reason. We’ve noticed running replica sets in Kubernetes with strategy helps reduce such blips and, hence retries. Note: Rolling Updates While this is an example using the Reactor Project’s implementation in Spring; all major frameworks and languages provide alternatives if you’re Spring Framework but not on reactive programming Spring Retry when you’re on Akka with Scala or Java Supervisor Strategy if you’re using Scala without any framework as such scala.util.{Failure, Try} in python Retry Decorator in JavaScript fetch-retry And I’m sure this is not an exhaustive list. This pattern takes care of transitory network blips. But what if there’s a sustained outage? More than later in this article. Last Known Good Version What if the called service continuously crashes and all retries from various clients exhaust? I prefer falling back to a last-known-good version. There are a couple of strategies that can enable this policy on the infrastructure and client-side. And we’ll briefly touch upon each one of them. last-known-good-version The simplest option from an infrastructure perspective is to redeploy to the last known stable version of the service. This is under the assumption that the downstream apps are still compatible with calling this older version. It’s easier to do this in Kubernetes, where it saves previous of deployments. Deployments revisions Another way is for the clients to save a last successful response they can fall back on in case of failures from the service, showing a stale data-related prompt to the end user on Browser or Mobile UI is a good option. Cached at downstream The browser, or any client for that matter, continuously writes data to an in-memory store until it receives a heartbeat from the upstream. This mechanism offers various implementations for both UI and headless clients that make service calls through gRPC or REST. Here is a summary of what to do, regardless of the type of client. Caching at downstream Clients are registered on their first API Call for the service to keep track Subsequent updates to the clients are managed as a push from the service to the client Clients retain the state locally, Redux on the browser; or Redis, Memcached for Headless clients (LinkedHashMaps too if your soul allows that) If you’re not at a scale to afford push, you can use tools like RTK for ReactJS and NgRx store for Angular and keep pulling state updates, be sure to inform the end-user that they might be seeing stale data when you get any of the 5XX status errors Patterns for sustained outages We’d be lucky if any distributed architecture were a system of only blips, which they are not. Hence, we have to build our systems to handle long-lived outages. Here are some of the patterns that help in this regard. Bulkheads Bulkheads address the contingency of outages caused by slow upstream services. While the ideal solution is to fix the upstream issue, it’s not always feasible. Consider a scenario where the service (X) you’re calling relies on another service (Y) that exhibits sluggish response times. If service (X) experiences a high volume of incoming traffic, a significant portion of its threads may be left waiting for the slower upstream service (Y) to respond. This waiting not only slows down the service (X) but also increases the rate of dropped requests, leading to more client retries and exacerbating the bottleneck. To mitigate this issue, one effective approach is to localize the impact of failures. For instance, you can create a dedicated thread pool with a limited number of threads for calling the slower service. By doing so, you confine the effects of slowness and timeouts to a specific API call, thereby enhancing the overall service throughput. Circuit Breakers Circuit Breakers can easily be avoided, we have to write services that will never go down! However, the reality is that our applications often rely on external services developed by others. In these situations, Circuit Breaker, as a pattern, becomes invaluable. It routes all traffic between services through a proxy, which promptly starts rejecting requests once a defined threshold of failures is reached. This pattern proves particularly useful during prolonged network outages in external services, which could otherwise lead to outages in the calling services. Nevertheless, ensuring a seamless user experience in such scenarios is vital, and we’ve found two approaches to be effective: Notify users of the outage in the affected area while enabling them to use other parts of the system. Allow the client to cache user transactions, providing a “202 Accepted” response instead of “200” or “201” as usual, and resume these transactions once the upstream service becomes available again. Conclusion The realization that, despite a cloud provider’s commitment to high availability, network failures remain an inevitability due to the vast scale and unpredictable nature of these networks, underscores the critical need for resilient systems. This journey immerses us in the realm of distributed computing, challenging us as engineers to arm ourselves with strategies for fault tolerance and resilience. Employing techniques like retries, last-known-good version policies, and the development of separate client-server architectures with state management on both ends equips us to confront the unpredictability of network outages. As we navigate the intricacies of distributed systems, the adoption of these strategies becomes imperative to ensure smooth user experiences and system stability. Welcome to the world of Microservices in the Cloud, where challenges inspire innovation, and resilience forms the bedrock of our response to unreliable networks. Also published . here

Managing the First Fallacy of Distributed Computing

Network architecture patterns impact player interactions but they come with their own pros and cons. The choice depends on the genre and interaction scenarios. We'll discuss the lockstep, rollback, snapshot interpolation, and lag compensation patterns and share the best choice for particular genres. Hello everyone, my name is Dmitrii Ivashchenko and I'm a Lead Software Engineer at MY.GAMES. We're continuing our series of articles examining the landscape of the in 2023", and this time, we'll be discussing different network architectures in various game genres. Unity Realtime Multiplayer Network architecture patterns Game developers use various network architecture patterns to ensure reliable and fast interactions between players in multiplayer games. Each pattern has its own advantages and disadvantages, and selecting the appropriate pattern depends on the specific game genre and interaction scenarios you're working with. In this section, we'll discuss the following patterns: lockstep, rollback, snapshot interpolation, and lag compensation. Additionally, we'll discuss the best-suited patterns for different genres or games. Lockstep is one of the oldest methods of synchronizing network gameplay, and it's still frequently used today. Although this architecture can take a variety of forms, we'll focus on the most common implementation, and then discuss the necessary conditions, limitations, and possible configurations. Lockstep In lockstep architecture, each player sends their input to everyone else, and then advances their simulation as soon as they receive input from all players — that's it! The game is fully synchronized over the internet, uses very little bandwidth, and each player always sees events unfolding exactly the same as everyone else. To make a game compatible with lockstep architecture, several conditions must be met. Let's discuss those. Determinism The main requirement for the lockstep architecture is that the game simulation must support strict, bit-level . Since network code only synchronizes input, the game simulation must compute identical results on each machine in each frame with identical input data. Otherwise, game simulations will desynchronize, diverge, and deviate from each other — ultimately leading to games that look completely different. determinism This is usually a difficult condition to satisfy, and games must be carefully designed to maintain determinism. Developers often check game state checksums on each frame or at multiple points during a frame and compare these checksums between participants to help track down and fix sources of non-determinism where desynchronization occurs during game testing. Further, any game that uses floating-point arithmetic (i.e., most modern games) will require additional consideration. If your game runs on multiple platforms, floating-point determinism can be particularly challenging to achieve due to differences between platforms and compilers. Each compiler can use different sets of instructions, reorder instructions, or automatically vectorize. Each system can implement transcendental functions such as cosine, sine, and tangent differently. All of this can lead to desynchronization between platforms, or even between builds. Some developers implement their game simulation exclusively using fixed-point arithmetic or software-emulated floating-point arithmetic to bypass the non-determinism that arises from using floating-point numbers. Other sources of non-determinism include generating random numbers with different seeds or processing objects in different orders, such as contacts in physics. All of these considerations also greatly limit the third-party libraries that can be used as part of the game simulation, such as collision detection libraries, physics engines, etc. As a result, this may be impractical for many genres of games and engines. Fixed frame rate Lockstep also requires all players to synchronize the unit of time represented by each input and tick. In other words, the game will progress at a fixed frame rate. Some games lock the rendering frame rate to match the fixed simulation frame rate. Others allow rendering at an arbitrary frame rate and show interpolation between fixed tick results. Issues and limitations Although the lockstep architecture is one of the simplest to implement and comes with no visual artifacts, there are a number of issues and limitations. In some cases, these limitations can be overcome by making certain compromises in the implementation of the game. In other cases, these limitations may simply limit the applicability of this architecture for a given game. Input delay Lockstep prevents any delay-induced visual artifacts by waiting to progress until all relevant information has been received. This waiting has a downside: input delay. “Input delay” usually refers to the time between the user pressing a button and seeing a response on the screen. From a user's perspective, they perceive a response to their input when they see the result of that input on the screen. If the user has to wait until all other players receive and process their input before they see this response, this can lead to a significant input delay. And in games with high reactivity requirements, such as shooters, input delay can be a critical factor, as it can make the game less responsive and more difficult to play. Rollback Moving on, is a popular network code architecture that is widely used in modern competitive games, especially in fighting games. rollback Rollback can be seen as an extension of the classic lockstep architecture. In the Rollback architecture, players send their commands each frame and continue their game without waiting for commands from other players. The game progresses without waiting for data from remote players — this is called "client prediction" because remote input data is not yet known, and the client must make assumptions about the future actions of other players. Compared to the lockstep architecture (which provides perfect sequence from frame to frame but with input delay) the rollback architecture provides instant command response, but at the expense of sequence. In the rollback process, the game progresses and this is immediately displayed as soon as commands from a local player have been sent. However, since commands from the remote player have not yet been received, the displayed information is a prediction. Once data from the remote player is received, this new information must be reconciled with the prediction. If the information does not match the prediction, the game is rolled back to "correct" the error. What is a "rollback"? Let's assume that new data from a remote player has arrived for frame 5 while the client was preparing to render frame 7. In this case, the client needs to take the following steps: Load/restore the state of the entire game as it was on frame 4, i.e. the last unpredictable frame where all commands were known. Move the game to frame 5 using the original local commands for frame 5 along with the newly received commands from the remote player. Continue advancing forward by applying local commands for each frame until we reach the current frame (in our example, this is frame 7). After completing these steps, we may notice that the actions of the remote player in frame 5 could have led to different outcomes than predicted; it is these corrected outcomes that will now be displayed in the game. Thus, "rollback" in this context means that the game "rolls back" to the last frame when everything was known, and then "replays" forward with new information. This provides the ability to correct prediction errors. It should be noted that for this to work, the game must be able to quickly save and restore its full state, as well as move forward any number of frames with arbitrary commands. Depending on the complexity of the game, this may require significant computational resources. Snapshot interpolation is a technique that was popularized by the game Quake, and it has since been widely used in games and game engines derived from Quake. Indeed, this model is particularly well-suited for shooters. Snapshot interpolation The snapshot interpolation approach is based on the concept of two separate temporal streams for game objects: one reflects the state of objects in the past, the other the expected state of objects in the future. The client (player) sends their commands to the server, which processes these commands, changes the state of the game, and then sends back a "snapshot" of the current state of the game to the clients. This snapshot contains information about all objects in the game at the time of its creation. To keep the game responsive, clients apply part of the commands immediately to some objects, predicting their behavior. This results in objects being simultaneously present on the player's screen in different states: are represented as they were at a certain point in the past. Interpolated objects are represented as they are expected to be at a certain point in the future. Predicted objects This creates an interesting dynamic, for example, when your predicted character tries to dodge an incoming projectile that is interpolated. This can be more difficult than it seems, because your character is moving in the future, while the projectile is in the past. Nevertheless, this model has a number of advantages: The game instantly responds to player commands; unlike the lockstep model, no input delay is required. The client side requires significantly less processing time compared to full rollback architecture. Objects are interpolated between known states obtained from the server, so objects only pass through states they have already been in. It's important to note that for effective use of this model, the game must be able to quickly process and transmit snapshots of the game state, as well to instantly respond to player commands. Best architectures for different gaming genres Each gaming genre imposes its own limitations on network latency, stability, and throughput. For example, MMO games require high throughput, low latency, and high stability. Meanwhile, first-person shooter (FPS) games require low latency and high throughput. In both genres, it's recommended to use a server-client topology with an authoritative game server and data exchange based on state and input. The following table below provides a comparative overview of network requirements, data exchange formats, recommended network topologies, and network patterns for different video game genres. Genre Network requirements Data exchange format Recommended network topology Recommended network patterns Real-time strategies (RTS) Low latency, high stability Input Peer-to-peer, Server-client with authoritative client-host Lockstep MMO High bandwidth, low latency, high stability State Server-client with authoritative dedicated game server Predictive, Snapshot Interpolation First-person shooters (FPS) Low latency, high bandwidth State and Input Server-client with authoritative dedicated game server, Peer-to-peer Predictive, Rollback MOBA Low latency, high bandwidth State and Input Server-client with authoritative dedicated game server Predictive, Rollback Cooperative games Medium bandwidth, low latency State and Input Server-client with authoritative client-host, Peer-to-peer Predictive, Snapshot Interpolation Racing games Low latency, medium bandwidth State and Input Peer-to-peer, Server-client with authoritative client-host Predictive, Rollback Fighting games Very low latency, low bandwidth Input Peer-to-peer Rollback Battle Royale High bandwidth, low latency State and Input Server-client with authoritative dedicated game server Predictive, Snapshot Interpolation Tower Defense Low bandwidth, medium latency State Server-client with authoritative dedicated game server, Relay/matchmaking server Predictive Match-3 games Low bandwidth and latency requirements State Server-client with authoritative dedicated game server, Relay/matchmaking server Predictive We can draw some conclusions by analyzing this table: Network requirements depend heavily on genre: for example RTS and FPS games require low latency to ensure smooth and realistic gameplay. The data exchange format also varies depending on the genre: most games use state and input exchange, but some, such as RTS and action games, use only input. Network patterns and topology are chosen based on the specific requirements of each genre: action and sports games usually use prediction and rollback, while MMO and RPG games usually use snapshot prediction and interpolation. Rolling on Each game has its own set of requirements and genre intersections, which imposes its own limitations on network interaction. In many cases, choosing a proven solution will be a better alternative to independent development. In this post, we reviewed the main patterns of network architecture in realtime multiplayer games. We also compiled a general table of recommended solutions for different genres. Of course, these recommendations are not final and universal, but they can serve as a starting point when choosing your architectural solutions. In the next article, we will review ready-made solutions for realtime multiplayer games.

Unity Realtime Multiplayer, Part 7: Architectures in Different Genres

a SWOT analysis is an evaluation of the fundamental, operational, technical, social, economic, and even to some degree administrative elements of a project. This is not a model to be used for trading purposes. (NFA, ) Note: DYOR Composed of four elements, Strengths, Weaknesses, Opportunities, and Threats, a analysis framework provides excellent insight for establishing a high-level understanding of the state of a project's well-being through the lens of a birds-eye view. SWOT It can help formulate decisions around which areas require more attention, set performance goals, and organize a foundational understanding of where a project is headed. Rarely (if ever) used in crypto, it is time to apply this timeless method of evaluation to the digital asset space. Today, Sia (SC), the OG marketplace and decentralized cloud storage provider that is based on a proof-of-work system, will get a SWOT. 💪 Strengths (Internal) (Helpful) Sia is one of the oldest remaining generation one projects that actually had its first token sale (at the time called Sianotes) before Ethereum ever had its own. Arriving on the scene in that generation also imbued a fundamental system architecture that is rooted in proof-of-work, arguably the most decentralized consensus model. Moreover, being rooted so early in the budding industry that was extremely tightly knit (due to very few participants) gave the project immense potential exposure to build relationships with many of today's most prominent market participants. Being an OG Whenever users are entering agreements for network resources, the SC coin must be locked up in an escrow account. Because Sia is a Proof-of-work system, there is no native "staking" modules, however, there is a strong resemblance of SFA (stake-for-access) business logic. This potentially can create positive medium-term upward pressure on the SC token price. Contract Model for Acquiring Network Services Cost Effective Storage Considering that Sia was established as far back as 2013 in an MIT Hackathon and its blockchain was operational in 2015, it is astounding that even after a multitude of new generation solutions came to market, Sia still remains one of the most affordable in terms of storage cost. Coming in at approximately $2.00 per Terabyte per month, Sia's storage costs rank 2nd across the entire decentralized market (behind only Filecoin) and leaps ahead of any centralized solution. Settlement with the SEC Both a strength and a weakness. Resolving issues with the SEC through a settlement positions Sia well to avoid regulatory kurfuffle in the future. In the event of any global crypto crackdown, a foundation of compliance gives them an opportunity to circumvent being targeted. Should other decentralized solutions that have not been able to and will not be given a chance to resolve their regulatory relationships, Sia will, by pure serendipity, inherit all of their market shares. The settlement was around their dual token model SC and SF. SC (Siacoins) have been deemed not a security, however, the SF (SiaFund) tokens were deemed a security as they pay out portions of revenue generated by utilization of the underlying network. SF is now registered with the SEC as a digital security. There are three applications that are already deployed as beta's/alpha's available on GitHub or are currently in the process of being developed that will serve as the endpoints that enhance user experiences. Renterd, hostd, and walletd. Renterd is a consumer-facing application for creating contracts and buying network storage. Hostd is an administrative panel for network storage providers to organize their operations. Walletd will serve as the focal point for interacting with SC and SF (Siafund) tokens. Development of User Interfaces The role of SC and its economic significance in the Sia ecosystem is very direct and simple. Given that the SC must be locked into contract escrows and that network utilities can only be paid for in SC, in the event that the demand for on-chain storage explodes, the unit value of SC should follow/lead very closely in tandem. If the token value explodes upwards, it can be assumed that over the next weeks/months, the amount of new contracts will likely increase. Strong Network-to-Token Dependency 😞 Weaknesses (Internal) (Harmful) Perpetual inflation of a digital asset exerts a constant downward drag on price. While the inflation rate (as a percentage of total circulating supply) will eventually taper off around the 2.9% mark, the simple fact that it never stops turns the SC into a poor choice for value retention. Unlimited max Supply Even though this problem is currently being addressed, the fact that after so many years on the market, they have not been able to provide something so fundamental/basic is a bit strange. While other projects are able to attract new users, Siacoin is unable to because of something as seemingly trivial as an interface. Lacking Adequate User Interfaces While Proof-of-work is the "puritans" Sybil protection mechanism, the application of it is very limited due to the prohibitive costs associated with its computation. Moreover, POW is subject to limitations based on the processing capabilities (as measured against the level of security provided). Having to work with POW in decentralized file storage systems creates design constraints that potentially hold back the system from realizing necessary levels of scalability. POW algorithm for Decentralized File Storage Both a strength and a weakness. In the SEC settlement, the Sia Foundation arrived at their SF (SaiFund) token being recognized as a security. With this acknowledgment, the ownership of SF is more convoluted than ever before and a huge turnoff for any potential investors because now they know that is they own SF they are immediately liable to the full extent of securities law. Settlement with the SEC Extreme Downwards Drag on Token Value The economic model does not position itself as overly effective, in fact, the majority of the tokeomic design is net-negative on the value of the digital asset itself. No incentive for providers to hold/keep the SC after getting paid, very weak incentive for users to speculate, perpetual inflation, strange (ineffective) attempts at implementing a burn mechanism, and a splitting token model (SC/SF) that accrues to the SF holders, only expediting selloff pressures. 🧐 Opportunities (External) (Helpful) The category that Sia is operating in is considered to be among the largest and primed for continued growth at a CAGR of ~23.4%. The demand for computation shall continue to rise alongside the development of mankind and all of his creations (especially with AI). As computation grows so does the need for memory in which to store all of its associated data. Growth of Decentralized Storage Sector 😳 Threats (External) (Harmful) Skynet Labs Shutdown The entire Sia ecosystem was initially conceived by Nebulas Inc., which later split into two entities that were wholly responsible for developing, promoting, and managing the network. One of these entities was Sky Labs, which contributed tremendously to the business development side of things, bringing tremendous value to the network in the form of new contracts. After the unwind and shutdown of it Sia experienced an ~88% drop in the total active contracts and had an equally strong decline in the instantiation of new ones. *Note on this, whenever the shutdown transpired, other environmental problems (namely Filebases technical hiccups) caused compounded issues. The decentralized Storage sector is easily one of the most promising in terms of the evergrowing market size. Coupled with the highly intelligent caliber of players at the table here that are improving functionality and presenting *potentially better storage solutions, Sia can be rendered suboptimal over the course of time and disregarded. Modernized Competition In crypto, community is everything. Siacoin's long history and insane funding (raising over $300 million USD) would incline us to think that they would have a strong community due to incentives, marketing, and affiliations with influencers. That is not so. The foundation overlooking Sia has disappointed and angered its community so many times with so many downright strange decisions (such as its massive $20,000,000 treasury burn where they literally said they don't know what to do with it because they are scared of potential taxes) that they have been loosing all their original believers and have not been able to recoup any of them. Significant decline of community Takeaway: This one's a heartbreaker. The Siacoin mission is great, but the technology is now so far behind, and the community so far detached that the project seems to be living on a prayer. A lot of delays, controversial system architecture decisions, bag fumbling by the foundation, and involvement with the SEC. There is a disbalance of positives to negatives, with the negatives outnumbering the positives and outweighing their importance. I give them tremendous respect and credit for being able to resolve things with the SEC and still prove the project to have staying power after the fact. Unfortunately, it seems that rather than being beneficiaries of the first generation, they fumbled the bag due to leadership errors and poor decisions; that gap seems to have tilted outside of the realm of a potential recovery and will be taken by newer generation projects. Conclusion: I really want to like Siacoin. I am a huge proponent of proof-of-work systems. I love the Generation One philosophies. However, the current objective state of Sia is disappointing. It seems that even if they deliver on all of their promises, it simply will not be enough to make the project as valuable as it was once perceived to be. Something that was not addressed in depth here is the controversial dual token model that Sia has within its ecosystem: SC and SF. Simply put, SC is the native token for conducting transactions and paying the network fees and SF is a token that earns a portion of all network fees. I am not a fan of dual token models because of how much it skews the vectors at which potential value is captured. Not to mention that SF doesn't even provide governance rights, and over 85% of the supply is owned by the Sia Foundation. Hell no. Would I invest in SC (Siacoins)? All respect to the project, I want to see them succeed, but under the current circumstances, I would never invest in the digital asset. No. Would I invest in SF (Siafunds)? Even though it is SEC-compliant and provides revenue, I simply do not believe that out of all the opportunities in the crypto industry, this one is worth spending time or taking a risk on. If you know something that I don't or feel as though I might have missed anything worth noting, please do share, I would tremendously appreciate some feedback. Thank you so much for reading, I hope this serves you well on your journey. Live long and prosper 🥂 Also published here.

The Siacoin (SC) SWOT Analysis

The cloud has been a relatively recent major breakthrough in the area of computer science. And most organizations have leveraged its benefits by moving their applications to the cloud. However, everything brings with it some pros as well as some cons. Ensuring the security of the applications stored and executing on third-party servers is a huge challenge. In this article, we will focus on Java and discuss various good practices and tools that enable us to secure Java applications in the Cloud. Scope In this article, we explore the best practices and tools for securing Java applications in the cloud. The article begins by highlighting the importance of securing Java applications in the cloud and the challenges that developers face in achieving this. It then discusses a few best practices for securing Java applications in the cloud, including secure network communication, authentication and authorization, input validation, encryption and hashing, and monitoring and logging. The article also covers various tools that developers can use to secure Java applications in the cloud, including IAM, WAFs, vulnerability scanners, code analysis tools, DevSecOps tools, encryption and key management tools, and container security tools. The article aims to provide a comprehensive overview of the best practices and tools for securing in the cloud to help developers build secure and reliable cloud-based applications. Java applications Securing Java Applications in the Cloud Security is one of the most intricate, extensive, and crucial facets of software development. However, software security is usually disregarded or reduced to merely a few tweaks at the end of the development cycle. The list of significant data security breaches totals 3 billion exposed records per annum, including some big names. If it can happen to them, it can happen to you too. A major contribution to the increasing Security breaches is the migration of applications to the Cloud, because of its distributed nature and involvement of third parties. However, we can utilize some practices and measures to make sure our application is secure on the Cloud as well and exposed to minimal attacks. The good news is that Java has been around for a while and has numerous built-in security mechanisms, being one of the most popular programming languages for developing cloud-based applications. The has undergone rigorous combat testing and is regularly updated to address emerging security flaws. A large variety of tools for profiling and reporting security concerns are also part of the Java ecosystem. Java Security package However, it's crucial to exercise caution even with a reliable development environment. Vulnerabilities might lurk in the background during the complicated process of application development. Securing Java applications in the cloud is a complex task that requires careful consideration of various security risks and the implementation of best practices and tools. Best Practices for Securing Java Applications in the Cloud We present here some practices that are suggested to be incorporated to create secure Java applications in the cloud: Clean Code Maintaining the utmost simplicity in your code without losing usefulness is advised since vulnerabilities like to lurk in complexity. Always write your code to reveal as little information as feasible. Code that is safe and easily maintained benefits from implementation details being hidden. We suggest some points to keep in mind for writing secure Java code: Use Java's access modifiers to your advantage. Your code will be better protected if you know how to specify various access levels for classes, methods, and their attributes. Anything that can be kept private ought to be kept private. The minimal API and interface surfaces should always be defined. Make components interact over the smallest feasible region by decoupling them from one another. Even if a breach just affects a portion of your application, others will still be affected. Avoid exposing Sensitive Information in the Source Code Developers should avoid hardcoding sensitive information such as passwords or API keys in the source code and instead use configuration files, environment variables, or key stores to store and manage such information. All personally identifiable information, such as credit cards, social security numbers, etc., is subject to the above password policy. Your application should exercise the utmost caution while handling any personal information that has been given to it. Implement Authentication and Authorization Authentication and authorization are essential security mechanisms for protecting Java applications from unauthorized access. Developers should implement robust authentication and authorization mechanisms to verify the identity of users, services, and systems that interact with the application. To achieve this, multi-factor authentication, password policies, access control lists, and role-based access control can be implemented. Implement Input Validation Input validation is an essential security practice that helps prevent attacks like and cross-site scripting. Developers should validate all input data received from users and other systems before processing it to ensure that it meets the expected format and does not contain malicious code or characters. This is particularly valid for anything that might be processed by another tool or system. For instance, if something has the potential to become an argument for an OS command line! SQL injection : When programmers build dynamic database queries that accept user input, they introduce SQL Injection risks. Any screen input field may be used by an attacker to insert SQL instructions into the input data. The program then executes the malicious SQL in the database as a result of a flaw in the code. Hence, don't use dynamic SQL, make use of prepared statements (with parameterized queries). Otherwise, never concatenate parameters to create SQL statements, which makes SQL injection attacks quite likely. Prefer putting saved routines to use, and always validate input on the whitelist. SQL Injection Cross-Site Scripting ( ) assaults take place when an attacker employs a web application to distribute malicious code to other users, typically in the form of a browser-side script. Cross-site scripting: XSS To prevent it, use a proven library to HTML encode your output for HTML contexts and filter inputs with a whitelist of permitted characters to keep Java code applications secure. Use JavaScript Unicode escapes for JavaScript. Avoid Serialization In Java, serialization is the process of turning an object into a binary byte stream so that it may be transferred between Java Virtual Machines and then recreated using the deserialization process. Serialization establishes an interface to Java classes by avoiding common field access control techniques like constructors and access modifiers. Remote inputs can therefore be converted into fully functional objects. So, it's crucial to avoid serialization, especially when working with classes that are security-sensitive. This is so that all class fields may be accessed since serializing a class produces a public interface. Always think about which fields are accessible before employing serialization because it may be intrinsically unsafe for the application. It is also said that overloading certain constructors and methods is said to impact the code. Try to avoid that as well. Implement Encryption and Hashing Encryption and hashing are critical security measures for protecting sensitive data in transit and at rest. Developers should use strong encryption algorithms such as AES or RSA to encrypt data in transit and use secure hash algorithms such as SHA-256 or SHA-512 to hash passwords and other sensitive data before storing them in databases or other storage systems. Avoid Exposing Implementation through Error Messages Production error messages might provide attackers with a wealth of data. Particularly stack traces can disclose details about the software you're running and how you're utilizing it. Keep stack traces hidden from end users. As an example, this also includes warnings for failed login attempts. The error message should read "Login failed" rather than "Could not locate that user" or "Incorrect password”, which would otherwise provide hints to the user about the underpinning technology stack and processing. Make sure the information is as hidden as you can. Implement Monitoring and Logging Monitoring and logging are essential security practices for detecting and responding to security incidents in real-time. Developers should implement robust monitoring and logging mechanisms to track application activities, detect anomalies, and generate alerts when security incidents occur. This can be achieved by using tools such as log4j, Logback, or Splunk to collect and analyze application logs.\ Tools for Securing Java Applications in the Cloud The below tools can be utilized to secure applications in the cloud effectively. Identity and Access Management (IAM) IAM is a cloud service that provides authentication and authorization mechanisms for securing cloud resources. IAM helps manage user identities, roles, and permissions, enabling developers to control access to cloud resources such as databases, storage systems, and APIs. and are popular IAM services for securing Java applications in the cloud. AWS IAM Google Cloud IAM Web Application Firewalls (WAF) WAFs are security tools that protect web applications from common attacks such as SQL injection and cross-site scripting. WAFs sit between the application and the user, inspecting incoming traffic and blocking malicious requests. Some popular WAFs for securing Java applications in the cloud include AWS WAF, Azure WAF, and Google Cloud Armor. Vulnerability Scanners Vulnerability scanners are tools that scan applications and infrastructure for security vulnerabilities. Vulnerability scanners identify security weaknesses and provide recommendations for remediation. Some popular vulnerability scanners for securing Java applications in the cloud include Qualys, Tenable, and OpenVAS. Code Analysis Tools Code analysis tools are tools that analyze source code to identify security vulnerabilities and coding errors. Code analysis tools use static code analysis and dynamic code analysis techniques to identify security flaws such as buffer overflows, SQL injection, and cross-site scripting. Some popular code analysis tools for securing Java applications in the cloud include Checkmarx, Fortify, and Veracode. DevSecOps Tools DevSecOps tools are tools that integrate security into the software development lifecycle. DevSecOps tools automate security testing, code analysis, and vulnerability management, enabling developers to identify and remediate security flaws early in the development process. Some popular DevSecOps tools for securing Java applications in the cloud include Jenkins, GitLab, and CircleCI. Encryption and Key Management Tools Encryption and key management tools are tools that enable developers to encrypt data in transit and at rest and manage encryption keys. Encryption and key management tools provide secure storage for encryption keys and ensure that only authorized users can access them. Some popular encryption and key management tools for securing Java applications in the cloud include AWS KMS, Azure Key Vault, and Google Cloud KMS. Container Security Tools Container security tools are tools that provide security for containerized applications. Container security tools monitor container activities, identify vulnerabilities, and provide runtime protection for containers. Some popular container security tools for securing Java applications in the cloud include Aqua Security, Sysdig, and Twistlock. Conclusion Securing Java applications in the cloud requires careful consideration of various security risks and the implementation of best practices and tools. Developers should focus on: Writing a code that encapsulates the implementation and hides the sensitive information from the network. Encryption should be employed in an inevitable case of sharing sensitive information over the network, or otherwise. Authentication and Authorization should be properly implemented to ensure access to the right information to the right person. Validating the input data as well as avoiding serialization to ensure that an external input cannot inject malicious code that takes over the system. This includes preventing SQL injections and Cross-Site Scripting. Monitoring and logging application activities for real-time detection of security breaches. There are several tools available for securing Java applications in the cloud, including IAM, WAFs, vulnerability scanners, code analysis tools, DevSecOps tools, encryption and key management tools, and container security tools. By following best practices and using the right tools, developers can build secure Java applications in the cloud and protect against security threats.

Securing Java Applications in the Cloud: Best Practices and Tools

Network security is an important aspect of cloud security because cloud-based systems and services are accessible over the internet, which makes them vulnerable to a wide range of security threats. In addition, many cloud-based systems and services are shared among multiple customers, which can make it harder to control access to sensitive information and maintain the security of the system. Cloud computing enables organizations to store large amounts of data remotely. However, as this data is stored off-premises, it becomes more susceptible to breaches, loss and leakage. Standard security mechanisms such as vulnerability scanners may not be enough because vulnerable assets might be ephemeral (only existing or connected to the network for a short time). Network security solutions, as part of a broader cloud security strategy, can provide layers of protection to keep data confidential and prevent unauthorized access. AWS provides several cloud-based network security solutions, including the and AWS Security Hub AWS Web Application Firewall. In this article, I’ll focus on the AWS Network Firewall, which acts as a traditional firewall, only within an Amazon Virtual Private Cloud (VPC). What Is AWS Network Firewall? Amazon Web Services (AWS) Network Firewall is a cloud-based network security solution that allows you to create and manage firewall rules for your VPC (Virtual Private Cloud) network. It is a fully managed service that makes it easy to protect your network from unwanted traffic, while still allowing authorized traffic to flow through. AWS Network Firewall provides a set of security rules that you can use to control traffic to and from your VPC. These rules can be based on a variety of criteria, such as source IP address, destination IP address, and port number. You can also use AWS Network Firewall to block traffic that is known to be malicious, such as traffic from known malicious IP addresses or traffic that is known to be associated with malware or botnets. AWS Network Firewall also allows you to create custom rule groups that contain your own security rules. This gives you a high level of control over your network traffic and allows you to create custom security rules that are specific to your organization's needs. AWS Network Firewall also provides logging and monitoring capabilities, allowing you to track network traffic, analyze network activity, and troubleshoot security issues. It integrates with other AWS services such as Amazon CloudWatch and Amazon S3, so you can easily store, analyze and access your firewall logs. How AWS Network Firewall Works AWS Network Firewall filters traffic within the network (between subnets), giving you a high level of control. Here's an overview of how AWS Network Firewall works: You create a firewall policy that defines the security rules that you want to apply to your network traffic. These rules can be based on a variety of criteria, such as source IP address, destination IP address, and port number. You create a firewall and associate it with the firewall policy. This creates the firewall and sets it up to apply the security rules defined in the firewall policy to traffic flowing into and out of your VPC. You configure your VPC network to route traffic through the firewall. This can be done by creating a VPC endpoint and routing traffic through it, or by configuring your VPC route tables to route traffic through the firewall. Network traffic flowing into and out of your VPC is inspected by the firewall and compared against the security rules defined in the firewall policy. If the traffic matches one of the security rules, it is allowed through the firewall and forwarded to its intended destination. If the traffic does not match any of the security rules, it is blocked by the firewall. The architecture of AWS Network Firewall includes the following components:** Firewall policies: A firewall policy defines the security rules that you want to apply to your network traffic. Firewalls: A firewall is an instance of the AWS Network Firewall service that is associated with a firewall policy. You can create one or more firewalls and associate them with different firewall policies to suit the specific needs of your organization. VPC route tables: You can create one or more VPC route tables and configure them to route traffic through the firewall. Getting Started with AWS Network Firewall AWS Network Firewall provides two different deployment options: centralized and distributed. With centralized deployment, a single firewall is created, and all of the traffic flowing into and out of the VPC is routed through it. In this way, it allows you to manage the entire network from a single location. With distributed deployment, you can create multiple firewalls and place them at different points in the VPC network. This approach allows for more granular control over network traffic, as it allows you to apply different security policies in areas. Getting started with AWS Network Firewall is relatively straightforward, and involves a few key steps: Configure VPC subnets: Before you can create a firewall, you will need to have a VPC and at least one subnet configured. You can use the AWS Management Console, AWS CLI, or the AWS SDKs to create and configure your VPC and subnets. Create a firewall policy: Next, you will need to create a firewall policy that defines the security rules that you want to apply to your network traffic. Create a firewall: Once you have a firewall policy, you can create a firewall and associate it with the policy. Modify VPC route tables: In order to route traffic through the firewall, you will need to modify the VPC route tables to include the firewall. You can use the AWS Management Console, AWS CLI, or the AWS SDKs to modify the VPC route tables. Test your firewall policy: You can test the firewall policy by sending traffic through the firewall and observing if it is blocked or allowed based on the security rules defined in the firewall policy. Conclusion Adding a firewall to your AWS servers is a crucial step in securing your network and protecting your data. AWS Network Firewall is a fully managed service that makes it easy to create and manage firewall rules for your VPC network. By implementing a firewall, you can control access to your network and block unwanted traffic, while still allowing authorized traffic to flow through. Setting up AWS Network Firewall involves configuring your VPC subnets, creating a firewall policy, and modifying your VPC route tables to include the firewall. It's important to test your firewall policy regularly to ensure that it's working as expected and to update and adjust it as necessary to keep your network secure. AWS Network Firewall also provides logging and monitoring capabilities, allowing you to track network traffic, analyze network activity, and troubleshoot security issues. This, combined with the scalability and cost-effectiveness of the cloud, make AWS Network Firewall an essential security tool for any organization that is using AWS servers. Top Image Source

Adding a Firewall to Your AWS Servers: Step by Step

What are Bitcoin and Ethereum? These are the two biggest and the most famous cryptocurrencies in the world, and it can’t be that you’ve never heard of them. But still, (ticker BTC) is a form of digital currency that meets the need of central authorities such as banks or governments. Instead, Bitcoin uses a peer-to-peer internet network to confirm purchases directly between users. Bitcoin Launched in 2009 by a mysterious developer known as Satoshi Nakamoto, Bitcoin (BTC) was the first and most valuable entrant in the emerging class of assets known as cryptocurrencies. is a decentralized blockchain with smart contract functionality. (ticker ETH or Ξ) is the native cryptocurrency of the platform. Among cryptocurrencies, Ether is second to Bitcoin in market capitalization. Ethereum was launched in 2013 by a programmer Vitalik Buterin. Ethereum Ether What is a wrapped coin/token? Wrapped Bitcoin (WBTC) brings Bitcoin (BTC) to the Ethereum (ETH) blockchain.  Why is that so crucial? One of the main points is that WBTC is in decentralized finance and it provides the owners of cryptocurrency with the freedom to explore other blockchains. If you want, it’s a kind of a bridge between a BTC coin and an Ethereum platform. Wrapped tokens are cryptocurrencies that are implemented in a different blockchain. The reason that wrapped tokens exist is for interoperability, which is the ability of a coin to work in a blockchain that normally does not support it. Benefits of wrapped tokens Wrapped cryptocurrencies boost the utility and liquidity of smart contract platforms and well-known decentralized finance (DeFi) apps. Other reasons to wrap cryptocurrencies may include ERC-20 token swapping or taking advantage of blockchain functions that a crypto asset might not have on its native chain. It’s faster and cheaper to make transactions using a wrapped version of BTC. The majority of blockchains have their own token standards and they sometimes can’t be used across multiple chains. Wrapped tokens allow non-native tokens to be used on a given blockchain. It’s quick. As for buying or selling Bitcoin, it could be quite time-consuming. But a wrapped Bitcoin (WBTC) in the Ethereum network is way quicker. When you wrap a token, you actually increase the security of your assets because you have control over private keys. Plus, intermediaries (DAO, smart contracts, or a wallet) focus on safe exchanges. And yet some drawbacks Custody Wrapped tokens still depend on a custodian to be minted (wrap) or burned (unwrap). If the custodian is somehow flawed, the wrapping or unwrapping process will be flawed as well. Expensive minting It’s quite evident that wrapping and unwrapping tokens are followed by gas fees, which can lead to slippage. Centralized The pivotal point of cryptocurrencies is to be a decentralized system. But wrapped tokens are issued by a custodian, and they tend to be centralized. According to Vitalik Buterin, wrapped tokens are “sensitive” to centralization because they’re created in a centralized manner. The matter is that wrapped tokens are minted through a central program, so they are an object of centralization.Good news, the benefits of wrapped tokens compensate for the negative sides though. How to wrap BTC? A wrapped BTC is a digital form of BTC blockchains that support smart contracts such as Ethereum, Solana, Polkadot, Binance Chain. Wrapped assets are just tokenized versions of Bitcoin that meet the token requirements of DeFi-supporting blockchains. Bitcoin wrapping techniques Here are three different options for tokenizing Bitcoin, all of them ask a user to lock BTC or other assets to get tokens pegged to the value of Bitcoin: Centralized This technique involves an intermediary. In this case, you need to send a necessary amount of BTC to a centralized custodial platform. After, this platform will lock your Bitcoin in a smart contract and mint an equal amount of tokenized Bitcoin on Ethereum or any other blockchain you need. Finally, the dealer will transfer the tokenized Bitcoin, WBTC, directly to your wallet. Trustless Using the following option, you do not need to trust a centralized side. You can send your Bitcoin to a smart contract adapted to mint tokenized Bitcoin quantity to the amount of locked BTC. Keep Network could be a good example of a system that uses a trustless technique. Synthetic The last Bitcoin wrapping option empowers users to get synthetic assets pegged to the Bitcoin value. Synthetic wrapping does not necessarily utilize BTC coin to mint a Bitcoin-pegged synthetic token. You can lock a combination of assets to mint synthetic Bitcoin. It really depends on the protocol you use. How to wrap Ether (ETH)? The process of generating WETH is fairly simple - you send your ETH to a smart contract that then sends WETH in return. This means that all WETH minted is backed up entirely by ETH reserves. To begin with, your ETH is locked in the smart contract and can be exchanged back at any time for WETH. When your ETH is returned, the contract burns the supplied WETH. To wrap Ether directly with the WETH smart contract, you need some ETHs and credit your wallet with WETH at a 1:1 proportion (you still need to pay transaction fees). Actually, it's much easier to swap another token for WETH using a crypto exchange. Where to store your WBTC and WETH? There are plenty of different options, of course, but we offer you something special, a . It was initially created for beginners, and the main aim was always to make all your crypto operations extremely safe. It supports 200+ currencies, and it’s just a promising beginning. The interface is intuitive and friendly, so you’ll never get lost within the wallet. You can have it as your favorite browser extension or as a mobile app. SimpleHold wallet Wrapping that up Wrapped tokens build a bridge between various blockchains. A wrapped token is, by nature, a tokenized version of an asset that natively operates on another blockchain. One of the biggest pros of wrapped tokens is that they provide greater scalability between different cryptocurrencies and blockchains and widen the opportunities for developers and traders.

What is Wrapped BTC and ETH (WBTC and WETH)?

Since the development of blockchain technology, the industry’s market structure has changed to center on Ethereum along with multiple coexisting chains. In terms of practical application, DeFi, NFT, GameFi, Web3, and other such ecosystems are developing very rapidly. Unfortunately, this growth has exposed Ethereum’s insufficient underlying performance problems. On top of that, high gas fees and network congestion continue to hinder the ecosystem’s expansion. As if this weren’t enough, some people seek to “rescue themselves” from Ethereum, focusing their attention on either Layer 2 or other public chain options. In 2020, the development of DeFi was seriously lagging, and many emerging public chains boasted lower fees and shorter confirmation times. Good examples of this included BSC, Solana, Terra, Avalanche, Fantom, Polygon, Arbitrum, Optimism, and Harmony, to name a few. Despite this, Ethereum remained the top choice for most DeFi projects, mainly due to the network’s high liquidity and transaction volume. But in the current DeFi era, where "liquidity is king," major public chains are using their high APYs to attract users. Indeed, according to statistics from DeFi Llama, the total value locked in DeFi on Ethereum had exceeded $161.5 billion as of October 22, 2021. Other public chains, such as BSC, Solana, and Avalanche, had achieved values of around $78 billion, forming a scale that simply cannot be underestimated. Essentially, the traffic that had initially accumulated on Ethereum was divided bit by bit until a fragmented “value island” had been formed. This phenomenon has only been further exacerbated by the increased number of Layer 2 projects that have cropped up over the past two years. In essence, the coexistence of multiple chains is the new market pattern. As more public chains appear, Layer 2 projects continue on, and respective ecosystems improve, the demand for cross-chain asset transfer will explode. Understanding Cross-Chain Bridges Put simply: a cross-chain bridge is a chain-to-chain connection that allows the transfer of tokens and assets from one chain to another. Since nearly all chains have their own protocols, rules, and governance models, they aren’t interoperable on their own. However, these bridges can facilitate communication and trade by making the two chains compatible with one another. Most cross-chain bridge designs include the following components: Oracle or Validator – This is responsible for monitoring the status of the source chain. Relayer - Transmits the information from the source chain to the target chain once the monitoring role receives the event. Consensus mechanism - In some modes, a consensus needs to be reached among the participants monitoring the source chain before this information can be relayed to the target chain. The consensus mechanism is designed to accomplish this. Signature - Participants are required to sign the information sent to the target chain cryptographically. This can be accomplished individually or as part of a multi-signature. In summary, most cross-chain bridges on the market are two-layer extended versions. Most of these - such as Arbitrum Bridges, Optimism Bridges, Polygon Bridges, etc. – are built on Ethereum. Since its DeFi ecosystem is relatively mature, other public chains see their primary goal as achieving cross-chain asset transfer with Ethereum. Of course, the current cross-chain bridge mainly serves the liquidity providers. This helps drain traffic for their own DeFi ecosystems, providing that there is enough APY to drive that traffic. It’s important to note that the rapid development of EVM-compatible chains and Layer 2 over the past year has allowed the network based on the Ethereum virtual machine to become increasingly diversified. In turn, people are gradually starting to realize that cross-chain asset transfer has more demand than previously anticipated. Market Performance of Cross-Chain Bridges According to the data monitoring of , as of March 28, 2022, the total value locked (TVL) of the 17 major cross-chain bridges included in the Ethereum overtime had reached approximately $25.2 billion. Of this, the current TVL of The Polygon was the highest ($5.8 billion). Next in line was Avalance Bridges, which boasted a TVL of $5.47 billion. The following bridges with top TVLs were Arbitrum Bridges, Ronin, and Fantom, which were still reported as a respectable $3 billion+. Dune Analytics At present, the Top 10 projects all had TVLs equivalent to more than $100 million. Of course, there are at least 100 cross-chain bridge projects on the market, all of them falling into one of four distinct categories. The first category includes official bridges like Wormhole, which is based on Solana, and the rainbow bridge, which is based on NEAR. These types of bridges offer nearly guaranteed levels of safety. The second category includes more professional and asset-based bridges, such as Ren Protocol, Keep Network, DeCus, and pNetwork. These tend to be alternative cross-chain bridges that focus on connecting Bitcoin to other networks. Unfortunately, they tend to be disadvantaged in their lack of capital efficiency. The third category includes third-party bridges with high versatility, such as Poly Network, Celer, Anyswap, Hop Protocol, and Synapse Protocol. Such third-party bridges have received widespread attention, putting them on the radar of many industry experts. The fourth category includes cross-chain bridge aggregators, which are still in the relatively early stages. The category’s central concept involves automatically matching and recommending the best cross-chain solution for every user. To do this, they plan to aggregate mainstream cross-chain bridges according to need. Third-Party Cross-Chain Bridges As Ethereum continues to expand, Layer 2 has come a long way. Currently, the ideal L2 solution involves the use of Rollups like Arbitrum, Optimism, StarkNet, and zkSynch. With Rollups, the goal is to package transactions that occur within a given period of time into a batch, then store the transaction data in the read-only area of the Rollup block. Once in place, that data can be published on the main chain (Ethereum) so that everyone can obtain L2 transaction data at any time. This will help monitor transactions by forming a consensus between the two layers. Rollup utilizes a series of compression schemes in order to process the original data and upload only a portion. The Merkle tree and the trusted proof calculations are performed off-chain, but the root hash of the Merkle tree and part of the transaction data are stored on the chain. Because of this distinction, it is critical that all off-chain activities be verified. Based on the difference in the proof method, there are two main schemes: ZK Rollup and Optimistic Rollup. ZK Rollup uses ZK SNARK cryptographic proofs, while Optimistic Rollup uses a fraud-proof/challenge mechanism. The latter requires a reasonable economic model in order to incentivize verifiers to participate in the process. At the same time, they need to disincentivize potential bad actors. Arbitrum Rollup's verification method also relies on fraud proofs, but with an improved challenge process. For fraud-proof/challenge mechanisms, some L2 solutions have security models that, in the interest of speed, aggregate transactions into batches before submitting them to the L1 Ethereum via a single transaction ( a process known as “assertion). These transactions are assumed to be valid by default but can be challenged down the line if fraud is suspected. Such a challenge will have a time window during which disputes can occur. That said, if a challenge is issued and upheld, the transaction behind the incorrect block will be deleted and “rolled” back. Because of this mechanism, users withdrawing assets from L2 to L1 will, in some instances, need to wait for an additional 7-days. Such challenge periods are currently in place on Optimism, Arbitrum, and several others. Therefore, without using third-party cross-chain bridges, users that wanted to transfer the ETH on Arbitrum to Optimism would need to return the ETH (Arbitrum Ethereum) on Arbitrum (L2) to ETH (L1) first. After that, they would need to wait 7 days before transferring the received ETH to the Optimism bridge. This is both a costly and time-consuming withdrawal period. In fact, this specific scenario is why a group of bridges is being implemented to provide cross-chain services between L1 and L2. On the whole, third-party cross-chain bridges are faster than official bridges, and there is no 7-day waiting period to withdraw assets from L2 to L1. That said, users need to pay extra to the market makers or protocols that provide cross-chain asset liquidity. This helps discount the time value of assets, reducing the potential loss caused by the 7-day vacancy. The Business Logic of Third-Party Cross-Chain Bridges To better explain this concept, let’s take a look at Hop Protocol, an early project of the third-party cross-chain bridges. Hop Protocol was created in January 2021 and functions as a Rollup-to-Rollup asset cross-chain bridge. When using Hop's solution, however, assets need to be transferred to the Layer 2 network through Hop itself. For example, ETH that enters the second layer through Hop's cross-chain bridges would become Hop ETH (or hETH). hETH and ETH are completely equivalent – that is, they can be exchanged through Hop. In terms of its specific implementation, Hop is mainly completed by the automatic market maker (AMM) and the Bonder. Basically, the Hop Protocol converts the user's Token into hToken, and then uses the Hop Bridge to transfer the hToken from Rollup 1 to Rollup 2. As of this writing, the Bonder has provided early liquidity for hToken in Rollup 2. This means Hop's AMM can automatically help users convert hToken into Token of the target chain, thus eliminating the 7-day withdrawal period. Key Users of the Third-Party Cross-Chain Bridges Hop Protocol requires two types of key users. The first is the arbitrageur. This is a user who buys tokens on one exchange and sells them for profit on another when there is slippage in the token’s price. Using Hop as an example, these users arbitrage on the spread between "hToken" and canonical tokens (such as hETH and Arbitrum ETH) on the Hop Rollup AMM and different Rollups. Eventually, as liquidity rebalances across AMMs, the price stabilizes. The second type of user is known as a liquidity provider. Similar to other AMMs like Uniswap, anyone can become an LP of the Hop pool, thus earning transaction fees. And since the liquidity of Hop AMM is provided via the same underlying assets (hETH, Arbitrum ETH, etc.), these can basically be redeemed for an equivalent amount from the mainnet. This ultimately has the effect of drastically reducing the risk of impermanent losses to LPs. Hop Protocol is an early project of the cross-chain bridge track, and one of the few to actually be delivered. The operation experience is very smooth, but it also has “first-mover” advantage. The initial operation of Hop began in early 2021, and business volume has grown rapidly since June of that year. In fact, the TVL has grown from less than $100,000 to $129 million, with liquidity mainly concentrated on Ethereum. At present, the growth rate has slowed down slightly, but the overall situation remains promising. According to the team , more than 60% of TVL was staked in the AMM liquidity pool, allowing seamless exchange between hToken and canonical token. The rest was staked by Bonders (market makers), who provided early liquidity to users of the target chain. The cumulative number of users of Hop Protocol had also grown to more than 50,000, and the business development data remains quite impressive. 's data at the end of 2021 Looking out across the market, we can see many products in the cross-chain bridge track, with fierce competition all around. Indeed, the recent TVL of the track leader is as high as $7.67 billion. What does this mean for the future? Well, it means that when cross-chain bridges are fully developed, they will need to allow seamless cross-chain assets transfer on each chain. To complete this seamless process, the cross-chain bridges need to: Multichain Be able to support both EVM and non-EVM compatible public chains. Solve the “impossible triangle” of interoperability protocols (no need for trust, scalability, information universality). And while the problem may actually be very difficult, it can be continuously improved upon via the corresponding short board. Have sufficient security, preferably to the point where there will be no need for trust. On the whole, the cross-chain bridge track already has a solid business foundation underneath it. Moreover, users demand for cross-chain bridges will always exist, so it will always be worthy of attention. Disclaimer Views expressed below are the analytical views of the . They should not form the basis for making investment decisions nor be construed as a recommendation or advice to engage in investment transactions. All information in this report comes from publicly disclosed sources. The viewpoints and forecasts only represent analysis and judgment as of the release date, and does not stay valid permanently. LD Capital LD Capital is a leading crypto fund that is active in primary and secondary markets, whose sub-funds include dedicated eco fund, FoF, hedge fund and Meta Fund.

Understanding Cross-Chain Bridges Under a Multi-Chain Background   

Comprensión de los puentes de cadenas cruzadas en un contexto de cadenas múltiples

Expense Breakdown: How Much Does it Cost to Create a Mobile App?

Scalability is often touted as the main bottleneck when it comes to the mainstream adoption of blockchain technology. And yes, scalability has been a thorn flesh. Multiple projects have been working on various blockchain scaling solutions, such as and . New architectures have also been developed, such as and , which offer greater scalability. Sharding Plasma Block Lattice Tangle However, an often over-looked factor when it comes to this discussion is Privacy. In the of Vitalik Buterin, words “When I and others talk to companies about building their applications on a blockchain, two primary issues always come up: scalability and privacy.” Who needs Privacy on Blockchain? Well, Buterin provides the answer again: “As seductive as a blockchain’s other advantages are, neither companies or individuals are particularly keen on publishing all of their information onto a public database that can be arbitrarily read without any restrictions by one’s own government, foreign governments, family members, coworkers and business competitors.” Imagine a scenario where a nation is ruled over by a totalitarian government. Whistle-blowers or rebels might need to keep their financial transactions outside the purview of the government. Now this may seem to be a bit drastic example, but think of nations torn by strife, and you will understand the gravity of the situation. Even in our personal lives, we would want to keep personal information such as identity data or medical records away from the prying eyes of others. If such information is hosted on a blockchain, then there is definitely a necessity for it to be private, allowing only a permissioned few to access such sensitive data. There has been significant research and development on the privacy aspect of blockchain as well. In this article, we will go over some of the past research, and take a look at some upcoming projects which are trying to solve the privacy problem. Bitcoin and CoinJoin The idea of CoinJoin was proposed by a developer by the name of Gregory Maxwell in 2013. A CoinJoin transaction essentially involves the combination of inputs by multiple users into a single transaction. If multiple users want to send BTC to multiple addresses, they can combine their transactions with one merged signature. Each user can publish a particular piece of the transaction, but the combined transaction can go through only when all the pieces are put together. For an observer, it becomes ‘almost’ impossible to deduce with certainty as to which output has been initiated by which user. Unfortunately, as the MIT Technology Review published in a , CoinJoin isn’t 100% failproof. Having said that, the success of a CoinJoin operation increases with the number of participants, which makes the technique encouraging from a scaling perspective. report Monero and Ring Signature is a cryptocurrency which ensures privacy and anonymity by employing the technique of Ring Signature – a created by a participant in a specified group. If the signature and public keys of all the group members are available, then anyone can verify if one of the participants provided the signature, but that particular participant can’t be identified. Monero digital signature Every time a user sends a Monero (XMR) transaction, the Monero wallet inserts keys from other users in the blockchain to form a ‘ring’. To an observer, anyone in the ring could have signed the transaction, and so the true identity of the sender remains obscured. Similar to CoinJoin, higher the number of participants in a ring signature group, greater is the degree of anonymity. Monero also introduced the concept of Stealth Addresses to hide the destination of funds. For every transaction, the sender generates a one-time address based on a public address used solely for that transaction. Every time XMR is sent, it’s sent to a new address, and these addresses cannot be linked together. ZCash and Zero-Knowledge Proofs The concept of zero-knowledge proof (or ZK proof) was first described in 1985 by Shafi Goldwasser and Silvio Micali. In cryptography, a ZK proof is a method by which one entity (the ‘prover’) can prove to another identity (the ‘verifier’) that they have the knowledge of a particular information without revealing the information itself. ZK proofs are the fundamentals on which various privacy techniques have been developed. , another privacy-focussed cryptocurrency, uses a type of ZK proof known as zk-SNARK to maintain the privacy of transactions. Zk-SNARKs ensure that transactions in the network can remain but still be verified as valid. ZCash encrypted The privacy features in Zcash are not active by default, but are dependent on an initial trusted setup between a prover and verifier. So, a set of public parameters is required to construct ZCash’s ZK proofs, and thus, the private transactions. Recent Developments , which still remains the foremost platform for deploying smart contracts, has integrated zk_SNARKs as part of the Byazntium update in 2017. Apart from Ethereum, a spate of recent projects have been working with ZK proofs and other privacy preserving techniques on the blockchain. Ethereum is using Multi-Party Computation (MCP) to develop a new privacy primitive for deploying smart contracts on public blockchains. Similar to ZK proofs, MCP enables a set of participants, each of whom hold a private input to a computation, to jointly learn the output of the computation without revealing to each other any information about the private inputs. Keep Network , a global DeFi network for creating and using confidential assets and smart contracts, uses both ZK proofs and MCP to support privacy-preserving features. This allows operators to verify the validity of transactions without observing the transactions’ private contents even in a private ledger. Findora , a cryptocurrency focussed on scalable and confidential transactions, is based on a protocol known as MimbleWimble. Introduced in mid-2016 by pseudonymous Tom Elvis Jedusor, MimbleWimble obfuscates transaction data such that it appears as random data to observers, while the actual details are only visible to the participants. Beam Parting Thoughts With scalability grabbing the major portion of the limelight, privacy has often been treated as a foster child by blockchain developers. However, privacy is directly tied to the security of a blockchain, which forms one of the 3 pillars of blockchain technology along with scalability and decentralization. Encouragingly, there seems to have been a shift in the mindset of developers in recent years, as they have gone about implementing new techniques to ensure that transactions remain confidential. As blockchain powered enterprises such as DeFi and asset tokenization continue to flourish, there is bound to be a greater demand for privacy in the cryptosphere. P.S. – The author has no vested interest in Monero, ZCash, Keep, Findora or Beam. (The author, obviously, holds both Bitcoin and Ethereum.)

Stories, News & Mentions about KEEPNETWORK

Keepnetwork’s Stories on HackerNoon

Keepnetwork's News & Mentions