ethix

0.0.2 • Public • Published

Ethix Core Architecture

Decentralized CDN + License Verification by incentivized cooperation and self healing network behaviors.

The ContentRegistry is a contract

A content registry holds ownership data and content metadata.

  • Users can claim ownership of content.
  • Owners can license content to be sold for a price.

LicensedContent is a contract

Generated by the ContentRegistry when an owner (or valid re-licenser (future)) associates a price with content and specifies terms of the license.

  • Terms might include:
    • Purchase expiration date
    • Number of NetworkRequests
    • Usage of license expiration date
  • Users can purchase licenses from a LicensedContent.

Each License is a contract

Generated by a LicensedContent when a purchase is made.

  • As Licenses are created, the address is logged along with the content id encrypted by the licencee's private key and the users wallet address.
  • The caller must have registered a public key with the system (if not available already)

A License can vend NetworkRequests (Better on a lightning network)

NetworkRequests are contracts to facilitate a single data transfer request.

  • Creating a NetworkRequest sets aside a portion of license fee as reward (or, part of the request cost)
  • The request costs a fee which will be refunded once the user reports the data was received (or failed).
  • Nodes call to claim the reward, first come first serve (up to 10/20/100, etc distributors).
    • As discussed below, multiple servicers might increase reliability but cause problems with effort validation.
  • If node will get reward, they can independently act to send data.
  • User reports back with who did what to reclaim extra NetworkRequest refund.
  • Nodes are now eligible to collect their fee for work done.

Users create NetworkRequests

  • A user has an address for the license contract, and the user can recover licenses by scraping logs.
  • A user generates a NetworkRequest via the License and passes in a routing address known to the CDN.
    • This should not be an ip, we don't need to broadcast location data, and we want nodes to be forced to use the network infrastructure for communication, which allows checks to detect bad actors.
    • The network can resolve the address via n hops and limited knowledge, and does not require opening a direct connection to that address.
  • Generating a request logs the NetworkRequest address, License address, network destination.

A p2p CDN distributes content

  • Nodes pay an initial fee to participate.
  • Nodes are removed if they behave badly, sacrifice the participation fee, and get blacklisted.
  • Nodes get rewarded for being well behaved and doing work.
    • The NetworkRequest is how a node can claim the reward for work.
    • The funds for the rewards are made available by the license.

The network sends data

  • A node reads the log of NetworkRequests and decides to act on a given request.
  • The node attempts to claim some reward (response time after request generation is faster on lightning).
  • With a successful escrow confirmation, the node sends requested data.
  • User receives data and finalizes the request.
    • The original sender node info is sent encrypted by the destination's public key.
    • This guarantess the receiver can properly validate the node during the request finalization.

The user confirms the result (or becomes a bad actor):

  • Invalidates the token for further usage.
  • Transfers collatoral payment back to user.
  • Moves reward payouts to claimable location.
  • Logs state change so distributor nodes can claim reward.

Self-healing goals and behaviors

  • Make it hard if not impossible for malicious nodes and clients to exist.
  • Any clients not finalizing requests might be blacklisted by other network nodes and ignored for data transfer.
  • Any distributors sending data through the network without being registered can be ignored.
    • They probably won't be able to handshake and join valid nodes.
    • Because destinations are network-relative, not beng a valid network node will hinder ability to route traffic.

Problematic features

  • Any distributors avoiding the license checking calls can be discovered and blacklisted.
  • Clients can verify logs after finalizing access. Only nodes that successfully called the NetworkRequest (and thus validated a license with permission to send data) behaved well, and this fact should be rebroadcast through the network on violation.
  • Of course, every validation step to solve a bad pattern exposes another point of failure for a malicious client. Imagine that a nasty client broadcasts false failures of other nodes. Since the client is the only able one to validate where data came from against where it should have come from, this operation needs to take place on chain during the finalize phase. This might involve a lot of extra state data since small file chunks delivered by multiple sources (scratch that feature?)... Can we rely on first come first serve contract winning node to fulfill data promise reliably? Can we implement time-based retry with different provider without spamming traffic?

Readme

Keywords

Package Sidebar

Install

npm i ethix

Weekly Downloads

0

Version

0.0.2

License

UNLICENSED

Last publish

Collaborators

  • randymarsh77