Only Dust

onlydust

How to Contribute to an Open Source Project As a Technical Writing

How Decentralized Interaction Protocols Work: Analyzing VC, ZKP, and Āut’s Interaction Tree

Empowering AWS DevOps With Python and Machine Learning

Liquity is a fascinating protocol, and this article aims to provide a detailed review. I am in no way affiliated with Liquity. I’m interested from a technical point of view because Liquity is one of the few original designs for a collateralized debt platform and also one of the few original designs for a crypto-backed stablecoin. Liquity's vision is to empower anyone to invest in high-yield assets, irrespective of their income level. Their mission is centered on enhancing access to on-chain borrowing by abolishing interest rates and minimizing the need for governance. In terms of volume, they have been a resounding success. They achieved a peak and currently maintain a TVL of $0.6 billion. Moreover, Liquity stands out as one of the and has maintained a record of zero hacks to date. Total Value Locked (TVL) of $4.5 billion most frequently forked projects in the space These achievements not only validate it as a solid product but are particularly impressive for a first release, especially considering the level of innovation Liquity incorporates. This article will explain how Liquity functions, drawing from my experiences in DeFi lending and liquidations. I will also share my perspectives on various features of the Liquity protocol. Let’s dive in. Liquity as a Low-Cost Permissionless Stablecoin Issuer Liquity can be described as a Collateralized Debt Platform, similar to , with the shared goal of issuing a stablecoin on a large scale. MakerDAO Liquity issues , a stablecoin loosely tied to the US Dollar. At the time of writing, there is , representing about 5% of volume or 30% of volume, the only two other significant crypto-backed stablecoins. LUSD $208 million of LUSD in circulation DAI FRAX For Liquity, borrowers are the most crucial users. The protocol's value increases as more LUSD is borrowed since this is the sole method for creating LUSD. Liquity has selected its features to ensure that borrowing LUSD is as convenient as possible. Additionally, they have integrated functionalities that provide customers with uses for LUSD. Liquity's strategy to attract borrowers leans on three main features: Low Collateralization Minimum Requirements Predictable, Low-Interest Rates A Dependable Borrowable Asset By focusing on these aspects, Liquity aims to attract borrowers, growing its own value. We will describe how Liquity’s implementation builds towards these three main features. Low Required Collateralization through Simplified Liquidations Liquity implements a streamlined liquidations system, aiming to make the job of liquidators easy and the liquidations themselves predictable. With efficient liquidations, they are able to reduce the required collateralization ratio below other protocols that need to protect themselves more against unpredictable liquidation performance. Liquity offers users to borrow LUSD by posting Ether as collateral. The , meaning that you only need to put $1100 worth of Ether to borrow $1000 of LUSD. That is very cheap, with rates for borrowing Ether-collateralized stablecoins usually at around 133%. minimum collateralization rate is 110% If the value of the collateral in a loan falls below 110% of the value of the loan, a liquidation will happen. The borrower won’t have to repay the loan but won’t recover their collateral either. Their loss will be the value of their over-collateralization or about 10% of their collateral value. If the Ether price falls quickly and the value of the loan falls below the value of the collateral before the loan is liquidated, Liquity itself would be the one accruing a loss. For this reason, Liquity implements an architecture and liquidations system aimed at resolving loan insolvency events as quickly and predictably as possible. Firstly, in Liquity, . In technical terms, this is much more complex and expensive than just storing all accounts in mapping and letting liquidators find who is collateralized and who is not. In Liquity, all loans are on a list, and you can just look at the top of the list to see if a liquidation needs to happen. all loans are sorted by their collateralization ratio Secondly, Liquity eases the work of anonymous liquidators by providing funding for liquidations. Liquity allows , which will be used to liquidate loans at risk and which will collect Ether as liquidations happen. __ __with 0.5% of the Ether used as collateral, plus a fixed 200 LUSD bonus. These features mean that Liquity doesn’t need sophisticated liquidators as other applications do. Liquidators only need to watch the collateralization ratio of the most at-risk loan and call a function if it falls under the collateralization ratio threshold of 110%. In other applications, liquidators would have to check all loans and would also have to use flash loans and swap applications to fund and profit from the liquidation. users to provide LUSD into a Stability Pool Liquidators will be rewarded Depositors into the Stability Pool make, on average, a 10% return on each share of their LUSD that was used to execute a liquidation. On the other hand, they obtain depreciating Ether, which they will need to hold, hoping for a rebound or sell quickly. Given their status as passive depositors, it is unlikely that the second option will be used often. The Stability Pool worked fine during and depositors were able to make a profit on the rebound of the Ether price. I think they were lucky. , an Ether price crash on 19/05/23 Recovery Mode as a Global Protection Mechanism Liquity has a built-in mechanism called , which activates when the aggregated collateralization of all loans dips below 150%. In this mode, the threshold for liquidating loans rises to 150%, immediately making all loans with collateralization ratios between 110% and 150% eligible for liquidation. These loans are processed in ascending order of their collateralization ratios. This means that only the loans at the highest risk are liquidated until the overall collateralization level returns to 150% or above. recovery mode While this mechanism is designed to enhance the system's safety beyond the standard liquidation process, it also introduces a new layer of uncertainty for borrowers, who now have to consider not only the ETH/USD exchange rate fluctuations but also the behavior of other borrowers on the platform. Redistribution Mechanism The Stability Pool exists in part to ensure funding for liquidations since LUSD might be in short supply in other venues like DEXs. Still, it can happen that the assets in the Stability Pool are less than the debt under liquidation. For those cases, there is a . redistribution mechanism With the redistribution mechanism, the debt and collateral of the loan are distributed among all other loans, effectively socializing the profit or loss from a liquidation among all borrowers. As well as making sure that lack of funding for liquidations (in the Stability Pool or DEXs) doesn’t result in the protocol accruing bad debt, it also socializes any eventual bad debt among borrowers, avoiding an eventual and catastrophic race for the exits if bad debt happens. It would be impractical to edit all loans when redistribution occurs, so Liquity uses to keep track of the amounts redistributed. The loans are updated whenever there is a later operation on them. accumulators like those in traditional rewards contracts Dust Limit as Protection Beyond the Stability Pool, Liquity has implemented a . This measure is intended to prevent the creation of loans that are not profitable to liquidate. minimum debt limit of 2000 LUSD on loans Drawing from my experience with Yield and discussions with industry peers, I find this minimum debt limit to be unnecessary. Such exploits have not been a significant issue for platforms operating without these limits. Moreover, imposing a minimum debt limit can be more burdensome for users compared to setting minimum collateral limits. With debt limits, users must fully repay their debt to avoid liquidation upon reaching the limit, a requirement that some may find challenging to meet. In contrast, minimum collateral limits do not pose this problem. Profits for Liquidators Additionally, Liquity incorporates an extra 200 LUSD of debt in each loan. This additional debt is not meant to be repaid by the borrower, nor is it provided to them, but it is factored into the loan's collateralization ratio. In the event of liquidation, the Stability Pool compensates for this added debt, paying out the of the liquidated collateral to the entity executing the liquidation. 200 LUSD plus 0.5% While the rationale behind this practice—to compensate liquidators for their expenses, such as gas fees—is understandable, the method of embedding additional debt into the loan seems convoluted. A more straightforward approach could involve the Stability Pool directly covering these expenses without affecting the collateralization ratio of the loan. Building Trust in LUSD Through Permissionlessness Liquity operates on immutable contracts and lacks a governance system. This feature builds trust in LUSD as a reliable asset, as it remains unaffected by the decisions of a governing body. However, a fully permissionless system comes with its own set of challenges. Firstly, it is impossible to patch the software if bugs are discovered. While many projects have struggled with this issue, Liquity continues to operate effectively. Secondly, once the product is live, it cannot be modified. This can be a problem if initial assumptions about user needs are incorrect. Despite this, Liquity has gained significant traction. The third challenge involves operational aspects, such as risk management and system maintenance. In a permissionless environment, these processes need to be either eliminated or fully automated. This requires a design approach that prioritizes simplicity and often leads to the exclusion of certain complex business features. Despite these obstacles, Liquity has successfully navigated these complexities. Their ability to overcome such challenges is commendable and noteworthy. Oracles in Liquity Liquity primarily uses Chainlink as its ETH/USD oracle. However, considering its permissionless nature, the platform also integrates a . This secondary oracle activates under specific scenarios where Chainlink might malfunction. backup oracle using Tellor Significant effort has been invested in designing a robust system for switching between the default and backup oracles. The criteria and conditions governing these transitions are detailed comprehensively . in this table Fees and Tokenomics One of the main selling points of Liquity is that of low, predictable fees. Liquity imposes a fee at the time of borrowing but does not charge ongoing interest, promoting predictability in loan costs and favoring long-term borrowing. This fee is dynamic, of the loan amount, calculated based on LUSD demand. Similarly, fees apply to LUSD redemptions, where LUSD is exchanged for Ether from Liquity’s reserves. ranging from 0.5% to 5% The accrued fees benefit LQTY holders. Since LQTY is not a governance token (aligning with Liquity’s governance-free structure), purchasing LQTY supports the development team and increases the value for existing LQTY holders in return for a share of the operational profits. With the ongoing development of Liquity v2 and the associated costs of promoting a stablecoin, this approach to monetization appears to be a reasonable strategy. Redemptions System An innovative aspect of Liquity is its . LUSD holders have the option to burn their LUSD in exchange for Ether, derived from the loan with the lowest collateralization ratio. This process allows LUSD holders to exit the system while simultaneously improving the collateralization ratios of the riskiest loans and the system as a whole. redemption mechanism This redemption feature plays a crucial role in maintaining the LUSD peg, ensuring the stablecoin’s value doesn’t fall far below the ETH/USD price feed. If the value of LUSD falls below that of USD, arbitrageurs will buy LUSD from the open market and redeem it for ETH at a profit. In the current high-interest scenario, . Any redemption leads to LUSD holders being forced to sell their LUSD if they want to exit the system, pushing the peg down and making redemptions more attractive. With the Stability Pool holding a large amount of existing LUSD and earning low returns, there is an exit flow from Liquity that leads to LUSD being sold and fuels this loop. the redemption system is leading to the unwinding of Liquity Currently, loans over 300% collateralized are being redeemed, forcing loan owners to sell their LUSD for ETH if they want to maintain their exposure to ETH prices. On the whole, guaranteed and forced redemptions seem problematic. Conclusion I personally find very interesting as a fully permissionless stablecoin issuer that has managed to gain considerable traction. While, in my opinion, the liquidation system is overly complicated, I still applaud the innovation. Liquity I think that Liquity might be one of the very few production systems using a doubly linked list, in this case, to order loans by collateralization ratio. Again, I think that a simpler system would have worked just as well, but I’m fond of those pushing the boundaries. Another of Liquity’s innovations is to entice LUSD borrowers to provide the LUSD as funds for liquidating loans at risk. This feature both simplifies liquidations and provides LUSD holders with a way to get a return on their holdings. As it seems to be the norm, I think this is overly complicated and unnecessary, at least from the liquidations perspective. On the side of the features within Liquity that I really like are their backup oracle system and their redistribution mechanism. From working on I know how difficult it is to design a truly permissionless but fault-tolerant oracle, and I believe that Liquity’s might be better than ours. , USMFUM Liquity’s redistribution mechanism is powerful and elegant, and I think it could have worked as the sole backup mechanism to a simpler liquidations mechanism if Liquity had decided not to use the Stability Pool. It is a design that I might steal for some future projects. In my view, Liquity is a highly successful proof of concept. I think that a simpler version could have worked as well, just drawing on the idea of a permissionless stablecoin. Still, such a quirky lending and liquidations system is great as a learning tool for all developers. The team is actively developing Liquity v2, which I expect to include features related to current topics like staked Ether as collateral and cross-chain execution. Whether it will be possible to maintain the permissionless ethos while adding new features remains to be seen. Or the team might choose to release a much simpler platform, aiming to become basic DeFi infrastructure instead. Whatever the features and outcome of new versions, Liquity v1 trialed out a wealth of new ideas at scale, and has earned its place among the greats. Thanks to @claudedonze for early reviews of this article and to @rick_liquity for his in-depth review and the background on many of the design decisions behind Liquity.

Liquity Review: A Permissionless Lending and Stablecoin Protocol

Off on a Comet! a Journey through Planetary Space by Jules Verne, is part of the HackerNoon Books Series. You can jump to any chapter in this book . A SEARCH FOR ALGERIA here CHAPTER X. A SEARCH FOR ALGERIA The , a strong craft of 200 tons burden, had been built in the famous shipbuilding yards in the Isle of Wight. Her sea going qualities were excellent, and would have amply sufficed for a circumnavigation of the globe. Count Timascheff was himself no sailor, but had the greatest confidence in leaving the command of his yacht in the hands of Lieutenant Procope, a man of about thirty years of age, and an excellent seaman. Born on the count’s estates, the son of a serf who had been emancipated long before the famous edict of the Emperor Alexander, Procope was sincerely attached, by a tie of gratitude as well as of duty and affection, to his patron’s service. After an apprenticeship on a merchant ship he had entered the imperial navy, and had already reached the rank of lieutenant when the count appointed him to the charge of his own private yacht, in which he was accustomed to spend by far the greater part of his time, throughout the winter generally cruising in the Mediterranean, whilst in the summer he visited more northern waters. Dobryna The ship could not have been in better hands. The lieutenant was well informed in many matters outside the pale of his profession, and his attainments were alike creditable to himself and to the liberal friend who had given him his education. He had an excellent crew, consisting of Tiglew the engineer, four sailors named Niegoch, Tolstoy, Etkef, and Panofka, and Mochel the cook. These men, without exception, were all sons of the count’s tenants, and so tenaciously, even out at sea, did they cling to their old traditions, that it mattered little to them what physical disorganization ensued, so long as they felt they were sharing the experiences of their lord and master. The late astounding events, however, had rendered Procope manifestly uneasy, and not the less so from his consciousness that the count secretly partook of his own anxiety. Steam up and canvas spread, the schooner started eastwards. With a favorable wind she would certainly have made eleven knots an hour had not the high waves somewhat impeded her progress. Although only a moderate breeze was blowing, the sea was rough, a circumstance to be accounted for only by the diminution in the force of the earth’s attraction rendering the liquid particles so buoyant, that by the mere effect of oscillation they were carried to a height that was quite unprecedented. M. Arago has fixed twenty-five or twenty-six feet as the maximum elevation ever attained by the highest waves, and his astonishment would have been very great to see them rising fifty or even sixty feet. Nor did these waves in the usual way partially unfurl themselves and rebound against the sides of the vessel; they might rather be described as long undulations carrying the schooner (its weight diminished from the same cause as that of the water) alternately to such heights and depths, that if Captain Servadac had been subject to seasickness he must have found himself in sorry plight. As the pitching, however, was the result of a long uniform swell, the yacht did not labor much harder than she would against the ordinary short strong waves of the Mediterranean; the main inconvenience that was experienced was the diminution in her proper rate of speed. For a few miles she followed the line hitherto presumably occupied by the coast of Algeria; but no land appeared to the south. The changed positions of the planets rendered them of no avail for purposes of nautical observation, nor could Lieutenant Procope calculate his latitude and longitude by the altitude of the sun, as his reckonings would be useless when applied to charts that had been constructed for the old order of things; but nevertheless, by means of the log, which gave him the rate of progress, and by the compass which indicated the direction in which they were sailing, he was able to form an estimate of his position that was sufficiently free from error for his immediate need. Happily the recent phenomena had no effect upon the compass; the magnetic needle, which in these regions had pointed about 22 degrees from the north pole, had never deviated in the least—a proof that, although east and west had apparently changed places, north and south continued to retain their normal position as cardinal points. The log and the compass, therefore, were able to be called upon to do the work of the sextant, which had become utterly useless. On the first morning of the cruise Lieutenant Procope, who, like most Russians, spoke French fluently, was explaining these peculiarities to Captain Servadac; the count was present, and the conversation perpetually recurred, as naturally it would, to the phenomena which remained so inexplicable to them all. “It is very evident,” said the lieutenant, “that ever since the 1st of January the earth has been moving in a new orbit, and from some unknown cause has drawn nearer to the sun.” “No doubt about that,” said Servadac; “and I suppose that, having crossed the orbit of Venus, we have a good chance of running into the orbit of Mercury.” “And finish up by a collision with the sun!” added the count. “There is no fear of that, sir. The earth has undoubtedly entered upon a new orbit, but she is not incurring any probable risk of being precipitated onto the sun.” “Can you satisfy us of that?” asked the count. “I can, sir. I can give you a proof which I think you will own is conclusive. If, as you suppose, the earth is being drawn on so as to be precipitated against the sun, the great center of attraction of our system, it could only be because the centrifugal and centripetal forces that cause the planets to rotate in their several orbits had been entirely suspended: in that case, indeed, the earth would rush onwards towards the sun, and in sixty-four days and a half the catastrophe you dread would inevitably happen.” “And what demonstration do you offer,” asked Servadac eagerly, “that it will not happen?” “Simply this, captain: that since the earth entered her new orbit half the sixty-four days has already elapsed, and yet it is only just recently that she has crossed the orbit of Venus, hardly one-third of the distance to be traversed to reach the sun.” The lieutenant paused to allow time for reflection, and added: “Moreover, I have every reason to believe that we are not so near the sun as we have been. The temperature has been gradually diminishing; the heat upon Gourbi Island is not greater now than we might ordinarily expect to find in Algeria. At the same time, we have the problem still unsolved that the Mediterranean has evidently been transported to the equatorial zone.” Both the count and the captain expressed themselves reassured by his representations, and observed that they must now do all in their power to discover what had become of the vast continent of Africa, of which, they were hitherto failing so completely to find a vestige. Twenty-four hours after leaving the island, the had passed over the sites where Tenes, Cherchil, Koleah, and Sidi-Feruch once had been, but of these towns not one appeared within range of the telescope. Ocean reigned supreme. Lieutenant Procope was absolutely certain that he had not mistaken his direction; the compass showed that the wind had never shifted from the west, and this, with the rate of speed as estimated by the log, combined to assure him that at this date, the 2d of February, the schooner was in lat. 36 degrees 49 min N. and long. 3 degrees 25 min E., the very spot which ought to have been occupied by the Algerian capital. But Algiers, like all the other coast-towns, had apparently been absorbed into the bowels of the earth. Dobryna Captain Servadac, with clenched teeth and knitted brow, stood sternly, almost fiercely, regarding the boundless waste of water. His pulse beat fast as he recalled the friends and comrades with whom he had spent the last few years in that vanished city. All the images of his past life floated upon his memory; his thoughts sped away to his native France, only to return again to wonder whether the depths of ocean would reveal any traces of the Algerian metropolis. “Is it not impossible,” he murmured aloud, “that any city should disappear so completely? Would not the loftiest eminences of the city at least be visible? Surely some portion of the Casbah must still rise above the waves? The imperial fort, too, was built upon an elevation of 750 feet; it is incredible that it should be so totally submerged. Unless some vestiges of these are found, I shall begin to suspect that the whole of Africa has been swallowed in some vast abyss.” Another circumstance was most remarkable. Not a material object of any kind was to be noticed floating on the surface of the water; not one branch of a tree had been seen drifting by, nor one spar belonging to one of the numerous vessels that a month previously had been moored in the magnificent bay which stretched twelve miles across from Cape Matafuz to Point Pexade. Perhaps the depths might disclose what the surface failed to reveal, and Count Timascheff, anxious that Servadac should have every facility afforded him for solving his doubts, called for the sounding-line. Forthwith, the lead was greased and lowered. To the surprise of all, and especially of Lieutenant Procope, the line indicated a bottom at a nearly uniform depth of from four to five fathoms; and although the sounding was persevered with continuously for more than two hours over a considerable area, the differences of level were insignificant, not corresponding in any degree to what would be expected over the site of a city that had been terraced like the seats of an amphitheater. Astounding as it seemed, what alternative was left but to suppose that the Algerian capital had been completely leveled by the flood? The sea-bottom was composed of neither rock, mud, sand, nor shells; the sounding-lead brought up nothing but a kind of metallic dust, which glittered with a strange iridescence, and the nature of which it was impossible to determine, as it was totally unlike what had ever been known to be raised from the bed of the Mediterranean. “You must see, lieutenant, I should think, that we are not so near the coast of Algeria as you imagined.” The lieutenant shook his head. After pondering awhile, he said: “If we were farther away I should expect to find a depth of two or three hundred fathoms instead of five fathoms. Five fathoms! I confess I am puzzled.” For the next thirty-six hours, until the 4th of February, the sea was examined and explored with the most unflagging perseverance. Its depth remained invariable, still four, or at most five, fathoms; and although its bottom was assiduously dredged, it was only to prove it barren of marine production of any type. The yacht made its way to lat. 36 degrees, and by reference to the charts it was tolerably certain that she was cruising over the site of the Sahel, the ridge that had separated the rich plain of the Mitidja from the sea, and of which the highest peak, Mount Boujereah, had reached an altitude of 1,200 feet; but even this peak, which might have been expected to emerge like an islet above the surface of the sea, was nowhere to be traced. Nothing was to be done but to put about, and return in disappointment towards the north. Thus the regained the waters of the Mediterranean without discovering a trace of the missing province of Algeria. Dobryna About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Jules Verne (1998). Off on a Comet! a Journey through Planetary Space. Urbana, Illinois: Project Gutenberg. Retrieved October 2022 https://www.gutenberg.org/cache/epub/1353/pg1353-images.html This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at , located at . www.gutenberg.org https://www.gutenberg.org/policy/license.html

A SEARCH FOR ALGERIA

Cyber breaches are a fact of life today, and with a , it’s a matter of when, not If, you experience a breach. With this trend projected to grow year-over-year, cyber resilience is increasingly becoming table stakes. Given the increase in supply chain-related , with nearly one-fifth of breaches occurring as a result of a breach in a company’s supply chain partners, it’s no surprise that company leadership and investors are demanding that all aspects of their business are protected and any organization they do business with is also cyber secure. 38% increase in cyber-attacks in 2022 cyber-attacks For large companies, stock prices may take a temporary hit but rebound quickly because they can devote immense amounts of resources, personnel, and finances to weather a cyber crisis. But a cyber breach can devastate startups and smaller companies running on much tighter budgets. And the costs of breaches are rising. In 2022, t , the highest since the inception of IBM’s annual Cost of a Data Breach report. he global average data breach cost was $4.35M So, what can companies that lack the resources of their larger counterparts do to protect themselves? As a serial start-up founder, I understand the specific challenges that emerging companies face. To insulate your organization from the ripple effects of a cyber breach and the associated costs and business disruptions, here are my four recommended to-do’s: 1. Assemble your SWAT team Any crisis for a small organization will likely be an all-hands-on-deck situation. When a crisis hits, you need to be confident and in control, and the best way to generate that sentiment is clearly defining who is handling what. Your SWAT team will likely include external partners to help shore up your cyber crisis response, including third-party services such as forensics, data recovery, and legal and public relations counsel. Begin researching these external partners early and communicate with them regularly to solidify your understanding of their capabilities during a breach. Coming together immediately is critical, as the first 48 hours of any cyber crisis are the most vital. Because many organizations run entirely on the cloud, you may need to operate under the assumption that your systems and your cloud services are compromised during a breach.  In today’s remote and hybrid workforce, it’s doubtful you’ll be able to gather everyone together in one physical room to attack the problem promptly. With a virtual “war room” already in place, your SWAT response team can be up and running in as little as 20 minutes. For external partners especially, the out-of-network war room is essential to share sensitive documents and securely execute your cyber response plan. 2. Spend the time to build a plan and then practice it The worst time to develop a plan is during a crisis. I experienced a cyber breach at a previous startup when an executive’s work laptop, containing a trove of sensitive information, was stolen. This is a real example of how many things out of your control can result in a breach. Fortunately, we already had a plan in place by implementing strong encryption on all laptops to wipe the data remotely. A guided plan outlining necessary steps can help mobilize everyone into action quickly and clearly. Ensure each team and individual knows their role during a cyber response and has immediate access to the plan. This is not the time for a lengthy document. The plan should be bite-sized to avoid impeding action efficiencies and elongating the impacts of the breach. As you develop your plan, consider the nuances of your industry and business operation across geographies and compliance protocols, which might require slightly different actions and reporting. Most importantly, your plan is useless if you only dust it off when a crisis strikes. Practice is imperative. Shift your company’s culture towards preparedness by discussing your cyber breach plans often. Remember, if your network is compromised, you may be unable to access your plan. Running scenarios is a great way to build cyber crisis response muscle memory. Companies with their plan available out of band and those practicing it are more resilient than 65% of all global organizations. 3. Don’t skimp on cyber insurance Many large enterprises require all tiered partners to have cyber insurance or risk losing their business. Walmart in 2021 required a regional HVAC supplier to purchase cyber insurance or risk losing a $100 million contract. An active insurance policy can mitigate the costs of a crisis for small businesses. The costs, resources, and external partners necessary during a cyber crisis can be surprising and, for smaller companies, often unrealistic. Even doing the bare minimum can deplete your company’s treasury, potentially triggering a death spiral for your company. Beyond covering direct costs, cyber insurance providers also have ready-to-go lists of recommended third parties vetted by the provider, reducing the time you spend researching and contracting with external partners. 4. Document actions and maintain records How you respond to a breach matters most. Consider the misstep of Uber’s former Chief Security Officer, who was convicted late last year of covering up a cyber-attack while the company was already under investigation by the FTC for earlier lapses in data management and protection protocols in 2016. While the decision to withhold information is illegal and clearly outside the company’s cyber crisis response plan, proper documentation protocols established by company executives could have included a system of checks and balances to hold themselves accountable. It can be easy in an emergency to lose track of who did what and when, but this is precisely what regulators, investors and cyber insurance providers will require you to report. Accurately documenting your response can minimize the long-tailed impacts of a cyber crisis and help your organization learn from the experience and fine-tune its response for future breaches. Early-stage startups and small organizations may only have a handful of employees at any given time. The startup mentality helps bind teams together to create a camaraderie that drives the company forward. Even as a company matures, this sentiment can remain strong. Company leaders owe it to their employees to protect their livelihoods by ensuring the business is prepared for any crisis, and the crisis you’ll experience is likely related to cybersecurity. By shifting the weight of a company’s cybersecurity culture to balance prevention and preparedness, companies can remain resilient in a crisis. Lead image generated with stable diffusion.

4 Essential To-Do’s to Boost Cyber Resilience

If you've spent much time around C# and .NET, it's likely that you will have come across , which allows you to use a range of powerful querying capabilities directly in the C# language. LINQ (Language-Integrated Query) The example below demonstrate a couple of common features of LINQ (note that I am using the extension method syntax rather than LINQ expressions). In the example, we have a list of people and want to obtain a list of names of the adults in that list. We will then iterate over those names twice (this will be useful to demonstrate the differences between immediate and deferred execution). Using LINQ, we can: Filter by age using Where Map from a Person object to the name string using Select Evaluate the query to a list using ToList { Name { ; ; } Age { ; ; }
} people = List<Person>
{ Person { Name = , Age = }, Person { Name = , Age = }, Person { Name = , Age = },
}; adultNames = people
    .Where(person => 
    {
        Console.WriteLine( ); person.Age >= ;
    })
    .Select(person => person.Name)
    .ToList(); ( name adultNames)
    Console.Writeline(name); ( name adultNames)
    Console.Writeline(name); public class Person public string get set public int get set var new new "Sam" 27 new "Suzie" 17 new "Harry" 23 var "Filtering by age..." return 18 foreach var in foreach var in /* output
Filtering by age
Filtering by age
Filtering by age
Sam
Harry
Sam
Harry
*/ Notice that in the above example, we explicitly convert the query to a list. This immediately executes the query to give a new list containing only the adult names, which we can then iterate over. So what happens if we leave off the ToList? adultNames = people
    .Where(person => 
    {
        Console.WriteLine( ); person.Age >= ;
    })
    .Select(person => person.Name); ( name adultNames)
    Console.Writeline(name); ( name adultNames)
    Console.Writeline(name); var "Filtering by age..." return 18 foreach var in foreach var in /* output
Filtering by age
Sam
Filtering by age
Filtering by age
Harry
Filtering by age
Sam
Filtering by age
Filtering by age
Harry
*/ Now the output looks quite different. Instead of doing all the filtering first, then iterating over the adult names, the filtering for each item is now happening immediately before we evaluate that item. Importantly, the filtering is also happening every time we iterate over the items. This is known as deferred execution, since we wait until we actually need the values to evaluate the query. Benefits of Deferred Execution It looks like deferred execution is the default behaviour of LINQ, unless you explicitly tell it to evaluate immediately (using ToList, ToDictionary etc.). So there must be some benefit to doing this, right? 1. Better Performance In most cases it is expected that deferred execution will result in better performance, since you don't have to execute the query on the whole data set at once. Instead, you perform the query on one item at a time as you are already iterating over it. 2. Query Construction Since the query does not need to be immediately executed, you can build it up in several steps, perhaps passing through additional conditional logic. This gives you additional power to create more complex queries. { query = people.AsEnumerable(); (onlyAdults)
    { query = query.Where(person => person.Age >= );
    }

    query = query.Select(person => person.Name); query.ToList();
} IEnumerable<Person> ( ) public GetNames IEnumerable<Person> people, onlyAdults bool var if // only add this filter when onlyAdults is true 18 return 3. Always revaluated Since the query is always revaluated on every enumeration, you can add/remove/change elements of you collection after the query has been constructed and the query will know about these changes. In this way, you know that you are always iterating over the most up to date data. people = List<Person>
{ Person { Name = , Age = }, Person { Name = , Age = }, Person { Name = , Age = },
}; adultNames = people
	.Where(person => person.Age >= )
	.Select(person => person.Name); ( name adultNames)
	Console.WriteLine(name);
		
people.Add( Person { Name = , Age = }); ( name adultNames)
	Console.WriteLine(name); var new new "Sam" 27 new "Suzie" 17 new "Harry" 23 var 18 foreach var in new "Sally" 26 foreach var in /* output
Sam
Harry
Sam
Harry
Sally
*/ The Pitfalls of Deferred Execution Despite so far singing the praises of LINQs deferred execution, this post was inspired by some of the issues I've been experiencing using it. One of it's benefits is also a pitfall if you do not take enough care when writing your code - the query is always revaluated. Although deferred execution is seen as a performance benefit generally, there can be cases where it can actually dramatically slow down your application if you're not careful. Any time that you know you will need to repeated iterate over the same collection numerous times (for example a nested for/foreach loop), make sure you call to list first. Otherwise, you will be evaluating the whole collection every single time, which will dramatically reduce performance. This is especially true if the source collection is particularly large since, even if your query does a lot of filtering, the query will be applied every time to the whole source collection. The final pitfall to mention is using `Select` to run a collection of tasks. I've seen arguments to say that this is something that you shouldn't do at all, but I've seen it enough in codebases to know that it's something that people do do and something you should be aware of. Imagine the below scenario: listOfIds = List< > { , , , }; tasks = listOfIds.Select(id => _repository.GetAsync(id)); Task.WhenAll(tasks); results = tasks.Select(task => task.Result).ToList(); var new int 1 5 8 15 var await var In the above example, the GetAsync method is actually executed twice for every ID, once when it is first declared, and a second time when the query is evaluated using ToList. Not only does this have a massive impact on performance by performing expensive operations multiple times, but also, since the task is re-executed, its not guaranteed to be completed when you actually come to evaluate it. As you might imagine, it is also particularly dangerous if the task you are running is actually a create or update operation (yes I have seen this too). To do the get safely, you need to immediately evaluate the query: tasks = listOfIds.Select(id => _repository.GetAsync(id)).ToList(); var Conclusion In this article I have introduced deferred execution in the context of .NETs LINQ. I have shown some of its features and why it can be beneficial compared to immediate execution. Finally, I have discussed some common pitfalls to looks out for when using LINQ and deferred execution. I post mostly about full stack .NET and Vue web development. To make sure that you don't miss out on any posts, please follow this blog and . If you found this post helpful, please like it and share it. You can also find me on . subscribe to my newsletter Twitter Previously published at https://samwalpole.com/linq-beware-of-deferred-execution

LINQ Query: Benefits of Deferred Execution

Three example configurations for the new OpenZeppelin access control contract. Access Control in Solidity. The new library from OpenZeppelin makes me happy Photo by from Scott Webb Pexels Restricting access to authorized users is really important in smart contracts. With $1 Billion locked in DeFi applications, you would really hope everyone knows what they are doing. Recently, I collaborated with OpenZeppelin to refactor the access control in their widely used repository. If you have ever coded a smart contract, most likely you have inherited from their code. openzeppelin-contracts In this article, I’m going to give you a walkthrough of how to use the revamped to restrict access to your smart contracts. I’ll do this through three examples. AccessControl.sol But first, let me tell you the story of how we got here. Please feel free to skip the next section if you are not interested in how this contract came to be and only want to learn how to use it. How we got here Getting here for me has been a process that took about a year. I first had the idea for a hierarchical role-based control contract in May 2019. I , along with some references to what OpenZeppelin was doing at the time. published the code in Medium I reused that code for and , becoming convinced that the implementation offered something both unique and powerful. From the lessons learned I wrote showing when to use , and . AllianceBlock Insig a second article Ownable.sol Whitelist.sol RBAC.sol To write that article I needed to research deeply into what OpenZeppelin had been doing in terms of access control. You don’t challenge the most-forked solidity repository without doing your homework. The OpenZeppelin team are really great guys, and shortly after they in the refactor of their access control contracts. Out of that collaboration we created an access control contract that is much more flexible than their previous approach, and much more robust than my previous approach. invited me to participate is available from the repository and I don’t keep a different codebase anymore. AccessControl.sol openzeppelin-contracts As an interesting aside, and as further proof of how important is access control, a version of existed back in 2016. It was Manuel Araoz’s towards what would become . Ownable.sol 9th commit openzeppelin-contracts In solidity years that is like digging dinosaur bones, and proves that access control is one of the very first things you should think about when coding smart contracts. Especially if you intend to code robust ones. Story time over, let’s dive into the code. How does AccessControl.sol work A role in is a struct that contains a set of addresses, representing the accounts bearing that role. All roles are stored in a mapping indexed by a bytes32 identifier, unique for each role. AccessControl.sol Each role also contains the bytes32 identifier of another role, which we call its admin role. There are internal functions to grant and revoke roles, and to set a role as the admin of another. These internal functions have no restrictions and you can use them if you are extending AccessControl.sol, as we will do later in this article. There are also external functions that restrict granting and revoking roles, as well as setting roles as admins of others. These functions can only be called externally by accounts that have been granted the admin role of the role being modified. As an example, imagine that we have two roles, DEFAULT_ADMIN_ROLE and USER_ROLE. DEFAULT_ADMIN_ROLE is the admin role for USER_ROLE. Only accounts that have been granted the DEFAULT_ADMIN_ROLE can grant or revoke USER_ROLE for an account. Likewise, only accounts that have been granted the DEFAULT_ADMIN_ROLE can redefine the admin role for USER_ROLE. A bit of magic worked here by was to define DEFAULT_ADMIN_ROLE as the uninitialized bytes32 variable. That means that all roles, by default, have DEFAULT_ADMIN_ROLE as the admin role. nventuro That’s it, let me show you in more detail with examples. Community replicates the functionality that existed in OpenZeppelin before. This contract Roles.sol There is a single role (DEFAULT_ADMIN_ROLE). Anyone that has that role can grant it to others. In roles can’t be revoked from a different account, but accounts can renounce to a role they hold. Community.sol The address passed on to the constructor is the first account being granted the role. pragma solidity ^ ; ; contract Community is AccessControl { (address root) public {
    _setupRole(DEFAULT_ADMIN_ROLE, root);
  } modifier onlyMember() { (isMember(msg.sender), );
    _;
  } { hasRole(DEFAULT_ADMIN_ROLE, account);
  } {
    grantRole(DEFAULT_ADMIN_ROLE, account);
  } {
    renounceRole(DEFAULT_ADMIN_ROLE, msg.sender);
  }
} 0.6 .0 import "@openzeppelin/contracts/access/AccessControl.sol" /// @dev Implements a single role access control contract. /// @dev Create the community role, with `root` as a member. constructor /// @dev Restricted to members of the community. require "Restricted to members." /// @dev Return `true` if the `account` belongs to the community. ( ) ( ) function isMember address account public virtual view returns bool return /// @dev Add a member of the community. ( ) function addMember address account public virtual onlyMember /// @dev Remove oneself as a member of the community. ( ) function leaveCommunity public virtual Administered implements a traditional setup with administrators and users. This smart contract DEFAULT_ADMIN_ROLE is the admin role of USER (by default). The address passed on to the constructor is the initial administrator. Admins can add other admins. Admins can grant and revoke user permissions to any accounts. The only way for an admin to lose its admin role is to renounce from it. pragma solidity ^ ; ; contract Administered is AccessControl {
  bytes32 public constant USER_ROLE = keccak256( ); (address root)
    public
  {
    _setupRole(DEFAULT_ADMIN_ROLE, root);
    _setRoleAdmin(USER_ROLE, DEFAULT_ADMIN_ROLE);
  } modifier onlyAdmin()
  { (isAdmin(msg.sender), );
    _;
  } modifier onlyUser()
  { (isUser(msg.sender), );
    _;
  } { hasRole(DEFAULT_ADMIN_ROLE, account);
  } { hasRole(USER_ROLE, account);
  } {
    grantRole(USER_ROLE, account);
  } {
    grantRole(DEFAULT_ADMIN_ROLE, account);
  } {
    revokeRole(USER_ROLE, account);
  } {
    renounceRole(DEFAULT_ADMIN_ROLE, msg.sender);
  }
} 0.6 .0 import "@openzeppelin/contracts/access/AccessControl.sol" /**
 * @title Administered
 * @author Alberto Cuesta Canada
 * @notice Implements Admin and User roles.
 */ "USER" /// @dev Add `root` to the admin role as a member. constructor /// @dev Restricted to members of the admin role. require "Restricted to admins." /// @dev Restricted to members of the user role. require "Restricted to users." /// @dev Return `true` if the account belongs to the admin role. ( ) ( ) function isAdmin address account public virtual view returns bool return /// @dev Return `true` if the account belongs to the user role. ( ) ( ) function isUser address account public virtual view returns bool return /// @dev Add an account to the user role. Restricted to admins. ( ) function addUser address account public virtual onlyAdmin /// @dev Add an account to the admin role. Restricted to admins. ( ) function addAdmin address account public virtual onlyAdmin /// @dev Remove an account from the user role. Restricted to admins. ( ) function removeUser address account public virtual onlyAdmin /// @dev Remove oneself from the admin role. ( ) function renounceAdmin public virtual Hierarchy This is the structure implemented in , with a minimal modification to build a hierarchy of roles safely. AccessControl.sol The address passed on to the constructor has the DEFAULT_ADMIN_ROLE, and is by default admin of all roles. I’ll call that address root. Root can grant the DEFAULT_ADMIN_ROLE to any account. Any root account can revoke the DEFAULT_ADMIN_ROLE role from any other account, so better not to grant it in the first place unless you know what you are doing. All roles exist from the beginning, as keys in a mapping. Any role can be granted or revoked by an account in the DEFAULT_ADMIN_ROLE. In each role has an admin role (DEFAULT_ADMIN_ROLE by default). In we allow for any account with that admin role can change the relationship and choose a new admin role. This can be used to build a hierarchy of roles, for example: DEFAULT_ADMIN_ROLE -> USER_ADMIN -> USER. AccessControl.sol Hierarchy.sol contract Hierarchy is AccessControl {
  event AdminRoleSet(bytes32 roleId, bytes32 adminRoleId); (address root) public {
    _setupRole(DEFAULT_ADMIN_ROLE, root);
  } modifier onlyMember(bytes32 roleId) { (hasRole(roleId, msg.sender), );
    _;
  } {
    _setRoleAdmin(roleId, adminRoleId);
  }
} /// @dev Add `root` as a member of the root role. constructor /// @dev Restricted to members of the role passed as a parameter. require "Restricted to members." /// @dev Create a new role with the specified admin role. ( ) ( ) function addRole bytes32 roleId, bytes32 adminRoleId public onlyMember adminRoleId It’s useful to have AccessControl.sol relevant code handy to understand what’s going on. abstract contract AccessControl is Context {
… { (
      hasRole(_roles[role].adminRole, _msgSender()), );
    _grantRole(role, account);
  } { (
      hasRole(_roles[role].adminRole, _msgSender()), );
    _revokeRole(role, account);
  } { (
      account == _msgSender(), );
    _revokeRole(role, account);
  }
  …
} /// @dev Grants `role` to `account`. ( ) function grantRole bytes32 role, address account external virtual require "AccessControl: sender must be an admin to grant" /// @dev Revokes `role` from `account`. ( ) function revokeRole bytes32 role, address account external virtual require "AccessControl: sender must be an admin to revoke" /// @dev Revokes `role` from the calling account. ( ) function renounceRole bytes32 role, address account external virtual require "AccessControl: can only renounce roles for self" Conclusion I’m really happy and really proud of having got to this point. Really proud because contributing code and ideas to is the strongest validation possible as a smart contracts developer. openzeppelin-contracts Really happy because finally the access control contracts that I’ve been using have now gone through a thorough audit and have been refined by masters in their field. I can now use them with complete confidence that they are right. And really proud and happy to contribute to the community. Giving back is the best present. Now it is up to you to continue. Please , , . BUIDL! use these contracts give feedback propose improvements

Using AccessControl.sol [A How-To Guide]

#buidlers have collectively deployed smart contracts worth millions of dollars over the past couple of years. Being one myself, I have been living with a realization of how overly dependent the entire ecosystem is on the intent of a developer. The end users, including investors, often don’t completely understand the smart contract code and the onus clearly lies on the developers. Ethereum blockchain With great power, comes great responsibility Often, critical functions of smart contracts are defined to be executed using the “onlyOwner” modifier. That leaves the smart contract owner with enormous power to make changes. This begs the question, who should have such powers? Broadly, powers can be given to either of these two 1) an Ethereum address or 2) a smart contract. Ethereum address based ownership Ethereum based ownership looks fundamentally flawed to me as this leads to obvious centralization, high risk of unintended code execution due to loss of private keys, interest misalignment etc. We saw the consequences of this when . They gave that wallet permissions to upgrade their smart contracts which made it a target for the hackers. It eventually got hacked and the attackers managed to steal Bancor’s assets using that wallet. This could have been avoided, had they implemented a kill switch by giving the permission to a smart contract rather than a wallet address. Bancor announced that a $23.5 Million worth of crypto assets were stolen from them by a hacked wallet contract EthAdressGoverned { address public owner; /*** Constructor sets the original `owner` of the contract to the sender account.*/constructor() public {owner = msg.sender;} @dev /*** Throws if called by any account other than the owner.*/modifier onlyOwner() {require(msg.sender == owner);_;} @dev } } Smart Contract based ownership A smart contract based ownership provides a trustless alternative, however, it again boils down to the permission system implemented by the smart contract. Note: If the smart contract uses the “onlyOwner” modifier with an ETH address as an owner, we are back to square one and the purpose of giving permission to a smart contract is defeated. So, how do we solve this? In both the cases, the point of failure is the authorization to a single Ethereum address eventually. Showcasing the common point of failure in both scenarios To solve this problem, we can either use 1) a multi-sig smart contract or a 2) a vote-driven smart contract based ownership model. Multi-sig smart contract based ownership In the past, projects (0x for example) used multi-sig wallets as they are easy to implement (somewhat). A multi-sig wallet requires a minimum number of signatures to authorize the transaction before it can be executed. This prevents unauthorized executions in case of an account hack. But the downside of a multi-sig wallet is that it offers less flexibility and the authority always remains in the hands of a selected few. Moreover, in case of an account hack, there is no way of executing critical functions that require all signatures. Vote-driven smart contract based ownership The issues of multi-sig wallets can be solved by using vote-driven smart contracts for defining the ownership and eventual governance of a dApp. I am aware of the enormous amount of passionate discussions around on-chain voting and its associated challenges with scalability. While I’ll be writing another article explaining how we aim to solve such challenges, I propose a mechanism of classifying a dApp community in multiple roles (like advisory board, developers etc) and combining such roles with configurable vote-threshold and majority-percentages. This way we can implement a flexible and scalable decision making model for dApps. Replacing Ethereum address based ownership with a self-governed smart contract For example, a decision to implement a kill-switch during an emergency (like The DAO hack) can be configured to require just an advisory board vote with a high majority and low threshold. However, a decision to revoke the emergency (after necessary corrections) may require Advisory Board + Member Vote with high majority and high threshold. is setting an example of using a vote-driven smart contract based ownership and governance. They are using the to govern their DAO which handles all critical functions of their smart contracts. model. Nexus Mutual govblocks-protocol More about Nexus Mutual’s governance This alone, isn’t the solution Despite the above mentioned solutions, there is still a high risk of human errors / ignorance that can unintentionally lead to a security breach and associated financial losses. Parity paid a price because their library contract was not initialized. That allowed anyone to become its owner and self-destruct it. As a result, all Parity multisig wallets became useless resulting in a loss of 514,000 ETH. when it’s multisig wallet got hacked Learning from past Conventional companies throughout the world are formed under the laws of their respective governments which mandate the filing of a company’s incorporation in a standardized format via a public registry. This is imperative to maintain transparency, uniformity and standardization in the process. Imagine if today we didn’t have a public registry of all companies in the world, it would lead to an uncontrollable menace of the company being at the behest of its owners with no accountability to other stakeholders whatsoever. A call for standardization How about we standardize (while remaining decentralized) the process of incorporating a dApp that can ensure compliance of the most critical steps, especially the ownership? We’ve been experimenting such ideas at and that led us to develop a contract called . This contract acts like a public registry of sorts and simply maintains a mapping of a dApp v/s its owners. An owner can be an ethereum address, multi-sig wallet or a vote-driven smart contract as discussed in previous sections. GovBlocks GovernChecker Once registered on the contract, a dApp can use the “ ” modifier throughout its smart contracts, thereby bringing in a great level of uniformity. The process is straightforward and . GovernChecker onlyAuthorizedToGovern detailed here We’re still in our early days of implementing the ‘code is law’ ideology and I feel that standardization along with a mechanism to update the law, pragmatically, is just as essential as figuring out the laws in the first place. Feel free to share your ideas in our & communities. Telegram Reddit Thanks to Ish Goel , Kartic Rakhra , Mudit Gupta for their ideas on this article.

Stories, News & Mentions about ONLYDUST

Onlydust’s Stories on HackerNoon