Happy new year to the Media family! It’s time for another update.

Many of our recent blog posts have had to do with helping developers understand the Media Network protocol effectively while providing monthly tech updates.

As the only dCDN in the market with a working product for DAOs and Web3 developers looking for alternatives to centralized CDN platforms, we wanted to review some of the most frequently asked questions on our social media channels about this groundbreaking technology available and ready to use in production today.

Let’s get started!

How does the protocol verify that content served from a Media Edge is not altered before it gets to the end-user?

These days, the most common way to verify that you have received or downloaded the proper file is to compute a checksum and compare it against one calculated by a reliable source. SHA-512 is frequently used to compute checksums -because it is computationally unlikely that two different files will ever have the same checksum. A checksum is a particular type of hash used to verify the integrity of a file. Verifying a checksum ensures no corruption or manipulation during the download, and the file was downloaded entirely and correctly. Media Guards constantly scan the network, sample Media Edge outputs, and check the files’ hashes against all existing ones on the origins using sha512sum.

SHA-512-(source_x) == SHA-512-(edge_x)

What happens when a Media Edge is caught serving manipulated data?

In that case, the Media Guard who identified it will request other guards to compare checksums while temporarily removing the malicious edge from the network for further analysis. Suppose the consensus is to remove this edge from the network permanently. In that case, its balance will get slashed (rewarding a portion of it to the Media Guard who identified it in the first place and burning the rest) and, by doing so, removed from the network permanently.

To run a Media Edge, you’ll be required to stake a considerable amount of LP MEDIA decided by the community, which would be at risk if the data is manipulated and discovered by a Media Guard.

Bad Data? SHA-512 and SRI To The Rescue!

Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch (for example, from a dCDN) are delivered without unexpected manipulation. It works by providing a cryptographic hash that a fetched resource must match. This is achieved by comparing the content with a cryptographic digest contained within the surrounding HTML tag. SRI makes sure that your files have been delivered without a third party modifying them on the fly.

SRI and the integrity attribute ensure that the file you linked to a page never changes. And if it does change, then the browser will reject it. Checking that code hasn’t changed is an old computer science problem with well-established solutions. SRI adopts the simplest — file hashing.

File Hashing

File hashing is the process of taking a file and running it through an algorithm that reduces it to a short string representation, known as a hash or checksum. The process is either repeatable or reversible, so much that if you were to give someone else a file along with the hash, they’d be able to run the same algorithm to check that the two match. If the file changes or the hash changes, then there’s no longer a match, and you know something is wrong and should distrust the file.

When using SRI, your webpage holds the hash and the server (CDN or anywhere) holds the file. The browser downloads the file, then quickly computes it to make sure that it matches the hash in the integrity attribute. If it matches, the file is used, and if not, it is blocked. This is key for any DeFi front-end to avoid allowing users to load hijacked websites and the following loss of customer’s funds such as Badger DAO front-end hack.

“BadgerDAO, a DeFi protocol for earning yield with tokenized Bitcoin on Ethereum, has fallen victim to an attack. The hacker reportedly added a malicious script to the protocol’s frontend website, prompting users to approve a smart contract transaction giving the script unlimited permission to drain funds from their wallets” https://cryptobriefing.com/120m-lost-badgerdao-defi-hack/

Using Subresource Integrity

SRI feature is easily implemented by specifying a base64-encoded cryptographic hash of a resource (file) you’re telling the browser to fetch in the value of the integrity attribute of any An integrity value’s “hash” part is, strictly speaking, a cryptographic digest formed by applying a particular hash function to some input (for example, a script or stylesheet file). <script src=”https://resourceid.medianetwork.cloud/jquery.min.js"integrity=”sha256-C6CB9UYIS9UJeqinPHWTHVq…”crossorigin=”anonymous”></script> <script>window.jQuery || document.write(‘<script src=”https://origin.com/jquery-.min.js"><\/script>')</script> Content Moderation / Inappropriate content Media Network is not a storage protocol or hosting provider, so cannot remove content from the internet that it does not host. However, the potential abuse of Media’s dCDN is a severe issue.  The community of developers and nodes that maintain the network treats these issues carefully. Unlike a traditional Web2 centrally controlled CDN, Media Network has tools for democratic moderation of its content built into the protocol's core - putting control of the network back into MEDIA holders. The Media Foundation can't control who or what resources are created, as everything is recorded on the blockchain and signed with users' wallets. Media Network has a similar approach to other protocols regarding inappropriate content such as: Individual Media Edge nodes can elect not to pull material from specific origins. Governance through the MEDIA token. Not only a utility token, but MEDIA is also a governance token which means the token-holders will decide in which direction the protocol goes. Governance through on-chain voting will directly modify the Media smart contracts and slash offenders' balances, bringing monetary trouble and hassle for malicious actors trying to serve inappropriate or illicit content using Media's dCDN. Consensus Mechanism Media Consensus is a two-layer system; the underlying blockchain secures the first transaction layer. The second layer is governed by the Media Smart-Contract inspired by DPoS (Delegated Proof of Stake) for MEDIA distribution. Media Guards play the validator role, allowing users to delegate their stake to a guard. Validations happen on-chain, and the protocol distributes fees and MEDIA tokens, slashing the stake of badly behaved actors. dCDN Billing: Time-Based Consumption All dCDN resources are billed hourly, up until a monthly cap. We have estimated that each month has about 672 hours (28 days). If you use your resource for less than 672 hours during the month, you will be billed for each hour that you use it. If you use your resource for more than 672 hours that month, you will be billed at the monthly cost, no greater than 672 hours.

Happy new year to the Media family! It’s time for another update.

Many of our recent blog posts have had to do with helping developers understand the Media Network protocol effectively while providing monthly tech updates.

As the only dCDN in the market with a working product for DAOs and Web3 developers looking for alternatives to centralized CDN platforms, we wanted to review some of the most frequently asked questions on our social media channels about this groundbreaking technology available and ready to use in production today.

Let’s get started!

How does the protocol verify that content served from a Media Edge is not altered before it gets to the end-user?

These days, the most common way to verify that you have received or downloaded the proper file is to compute a checksum and compare it against one calculated by a reliable source. SHA-512 is frequently used to compute checksums -because it is computationally unlikely that two different files will ever have the same checksum. A checksum is a particular type of hash used to verify the integrity of a file. Verifying a checksum ensures no corruption or manipulation during the download, and the file was downloaded entirely and correctly. Media Guards constantly scan the network, sample Media Edge outputs, and check the files’ hashes against all existing ones on the origins using sha512sum.

SHA-512-(source_x) == SHA-512-(edge_x)

What happens when a Media Edge is caught serving manipulated data?

In that case, the Media Guard who identified it will request other guards to compare checksums while temporarily removing the malicious edge from the network for further analysis. Suppose the consensus is to remove this edge from the network permanently. In that case, its balance will get slashed (rewarding a portion of it to the Media Guard who identified it in the first place and burning the rest) and, by doing so, removed from the network permanently.

To run a Media Edge, you’ll be required to stake a considerable amount of LP MEDIA decided by the community, which would be at risk if the data is manipulated and discovered by a Media Guard.

Bad Data? SHA-512 and SRI To The Rescue!

Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch (for example, from a dCDN) are delivered without unexpected manipulation. It works by providing a cryptographic hash that a fetched resource must match. This is achieved by comparing the content with a cryptographic digest contained within the surrounding HTML tag. SRI makes sure that your files have been delivered without a third party modifying them on the fly.

SRI and the integrity attribute ensure that the file you linked to a page never changes. And if it does change, then the browser will reject it. Checking that code hasn’t changed is an old computer science problem with well-established solutions. SRI adopts the simplest — file hashing.

File Hashing

File hashing is the process of taking a file and running it through an algorithm that reduces it to a short string representation, known as a hash or checksum. The process is either repeatable or reversible, so much that if you were to give someone else a file along with the hash, they’d be able to run the same algorithm to check that the two match. If the file changes or the hash changes, then there’s no longer a match, and you know something is wrong and should distrust the file.

When using SRI, your webpage holds the hash and the server (CDN or anywhere) holds the file. The browser downloads the file, then quickly computes it to make sure that it matches the hash in the integrity attribute. If it matches, the file is used, and if not, it is blocked. This is key for any DeFi front-end to avoid allowing users to load hijacked websites and the following loss of customer’s funds such as Badger DAO front-end hack.

“BadgerDAO, a DeFi protocol for earning yield with tokenized Bitcoin on Ethereum, has fallen victim to an attack. The hacker reportedly added a malicious script to the protocol’s frontend website, prompting users to approve a smart contract transaction giving the script unlimited permission to drain funds from their wallets” https://cryptobriefing.com/120m-lost-badgerdao-defi-hack/

Using Subresource Integrity

SRI feature is easily implemented by specifying a base64-encoded cryptographic hash of a resource (file) you’re telling the browser to fetch in the value of the integrity attribute of any An integrity value’s “hash” part is, strictly speaking, a cryptographic digest formed by applying a particular hash function to some input (for example, a script or stylesheet file). <script src=”https://resourceid.medianetwork.cloud/jquery.min.js"integrity=”sha256-C6CB9UYIS9UJeqinPHWTHVq…”crossorigin=”anonymous”></script> <script>window.jQuery || document.write(‘<script src=”https://origin.com/jquery-.min.js"><\/script>')</script> Content Moderation / Inappropriate content Media Network is not a storage protocol or hosting provider, so cannot remove content from the internet that it does not host. However, the potential abuse of Media’s dCDN is a severe issue.  The community of developers and nodes that maintain the network treats these issues carefully. Unlike a traditional Web2 centrally controlled CDN, Media Network has tools for democratic moderation of its content built into the protocol's core - putting control of the network back into MEDIA holders. The Media Foundation can't control who or what resources are created, as everything is recorded on the blockchain and signed with users' wallets. Media Network has a similar approach to other protocols regarding inappropriate content such as: Individual Media Edge nodes can elect not to pull material from specific origins. Governance through the MEDIA token. Not only a utility token, but MEDIA is also a governance token which means the token-holders will decide in which direction the protocol goes. Governance through on-chain voting will directly modify the Media smart contracts and slash offenders' balances, bringing monetary trouble and hassle for malicious actors trying to serve inappropriate or illicit content using Media's dCDN. Consensus Mechanism Media Consensus is a two-layer system; the underlying blockchain secures the first transaction layer. The second layer is governed by the Media Smart-Contract inspired by DPoS (Delegated Proof of Stake) for MEDIA distribution. Media Guards play the validator role, allowing users to delegate their stake to a guard. Validations happen on-chain, and the protocol distributes fees and MEDIA tokens, slashing the stake of badly behaved actors. dCDN Billing: Time-Based Consumption All dCDN resources are billed hourly, up until a monthly cap. We have estimated that each month has about 672 hours (28 days). If you use your resource for less than 672 hours during the month, you will be billed for each hour that you use it. If you use your resource for more than 672 hours that month, you will be billed at the monthly cost, no greater than 672 hours.