XLP-Manual Chapter 8. Technical Analysis

From MIT Technology Roadmapping
Jump to navigation Jump to search
Chapter 7
Back to Content Page
Chapter 9
English version /Chinese version

Containerization

Containers are the foundation of XLP, the Remix platform, and XLP’s Digital Publishing Work- flow:

  • XLP creates replicable, containerized learning missions, which can then be deployed and scaled up anywhere in the world
  • Remix provides the infrastructure to perform this digitally-i.e. Docker and Kubernetes
  • participants create containerized digital assets using XLP’s Digital Publishing Workflow,

as a record and proof of the work they have performed in the mission.

Docker Containers

Docker is an operating system abstraction layer, providing an abstraction boundary which manages collective boundaries and experience for its users. A Docker container ’contains’:

  • An operating system(oftenLinux/Windows/MacOS)
  • The programs you want to run on the operating system (for example, WordPress/Mediawiki)
  • The application and configuration data for the program (for example, WordPress media

assets, WordPress configuration details)

  • The data for the program(if WordPress,a database of MySql/Mariadb)

This container and its data(volume) can be save/exported from the Docker filesystem and be loaded, for easy deployment anywhere.

Like an operating system, Docker:

  • Authenticates the container via its hash
  • Schedules priorities, for example what resources the container has access to
  • Manages input and output, for example how many of the host machine’s resources it may use.

What do We Run in Docker?

Figure 8.1: Remix’s Docker infrastructure

Namespaces

Computers operate on levels of abstraction. Otherwise we would be dealing directly with ones and zero’s. A common kind of abstraction is a namespace, which organizes and names objects. Some examples include:

  • Memory registers: Each register has it’s own unique address
  • Filenames: Each file on a system has it’s own unique path and filename combination
  • URLs: Each website is reached via different URL

Containers also have their own unique namespace, namely their 256-bit hash. An example hash (shown in hexadecimal format) would be:

7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069

This hash acts as a digital fingerprint, and is highly secure since there are 25632 combinations which would take 3x1051 years to crack if using fifty supercomputers.

Verification and Security

With filenames or URLs, you have no guarantee you’ll actually get what you think you’ll get. Today *google.com* might take you to a search engine. Tomorrow Google may get hacked and you could end up on a site that *looks* like Google but steals your login credentials.

Containers are different. Since Docker hashes are unique and unforgeable, we can verify a Docker container and add it to a database of other verified containers. When you’re then de- ploying that container, you can check that hash matches the hash in our database, thus ensuring the container will run consistently. This can be thought of as similar to the police comparing fingerprints of known criminals with fingerprints at a crime scene.

Secure Concurrent Editing

A potential barrier with generating big data simultaneously across a distributed network is the Byzantine Generals Problem5: Reliable computer systems must handle malfunctioning components that give conflicting information to different parts of the system.

In an abstract sense, this can be expressed as a group of generals camped with their troops around an enemy city. They can only communicate by messenger to agree on a common battle plan. However, one or more of them may be traitors who will try to confuse the others. So, how can we find an algorithm to ensure that the loyal generals will reach agreement?

It is shown that, using only oral messages, this problem is solvable if and only if more than two-thirds of the generals are loyal; so a single traitor can confound two loyal generals. With unforgeable written messages, the problem is solvable for any number of generals and possible traitors.

In XLP, the problem can be seen as failing to process large amounts of data at the same time. The solution is a distributed repository (like Git) allowing all participants to transparently see what content others contribute. This increases everyone’s confidence in the trustworthiness of their fellow participants, thus making them more likely to contribute and share content, and that this content will be compiled into a consistent result.

XLP uses existing computing science techniques that improve the ability to process the concurrent publishing of massive amounts of distributed intellectual content. Bitcoin also ensures Byzantine fault tolerance – in other words, solves the Byzantine Generals Problem – by incorporating a distributed database that lets any participant view the entire history of trans- action records. This enables the processing and compiling of massive amounts of intellectual resources on an Internet scale. Open-source version control software, like Git, Concurrent Ver- sions System (CVS), and Apache Subversion (SVN), also enable sharing of human-contributed content – be it source code, novels, textual content, movies, or photographs – and enable the processing and compiling of data on a massive scale.

Decentralization

By using computer-generated smart contracts stored on technologies similar to Blockchain, organizations that practice XLP can run as a decentralized autonomous organization (DAO). This means that participant performance can be assessed algorithmically and stored securely on their lifelong digital learning profile. Using Blockchain ensures XLP abides by the principles of Trustworthy Computing, giving participants, organizations, and employers faith in the quality of work.

Tokenization

Tokenization goes hand in hand with the theory of containerization. Any kind of digital information can be seen as a data container, and every container can be broken down into smaller containers. For example, this XLP manual is a container, which contains the necessary information for executing XLP. The XLP manual container consists of sub-containers - one of them is this section.

Modern Blockchain (Distributed Ledger) technology can be used as a common representation of any type of container. A token is simply all bundled information for uniquely representing a container on a distributed ledger. This token uniquely identifies a distinct container and guarantees its authenticity. tokens can be used as a proof of authorship, as well as ownership and hence used for trading and sharing containers.

This section will present the most important history and technical concepts which enable tokenization. Then, distributed ledger technology is discussed. Lastly, the necessary architecture for the XLP-Token-System (XTS) is derived and presented.

Distributed Ledger Technology(Blockchain)

In 2009, Satoshi Nakamoto the paper ”Bitcoin: A Peer-to-Peer Electronic Cash System”<ref>Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. [online] Available at: https://bitcoin.org/ bitcoin.pdf [Accessed 7 May 2017].</ref>. In his work he describes a global decentralized system for exchanging tokens. The inherent tokens digitally represent a monetary value and are labeled as Bitcoins.

This system, called a Blockchain or Distributed Ledger (DL) can be created by combining avail- able technologies and algorithms such as:

  • Public-private-key cryptography
  • Digital signatures
  • Digital timestamps
  • Peer-to-peer protocols
  • Cryptographic hashes
  • Merkle trees

Additionally, a DL system needs a consensus algorithm for reaching agreement between the distributed participants. Such a consensus algorithm ensures that there is a global world state of values, on which the majority of participants agree. In Bitcoin, this system is called Proof-of- Work and relies on participants using their computing power for solving a randomized ”riddle”.

Four Forces

XLP activities are executed in a highly technical context, which takes into account the Four Forces discussed previously. These forces require:

Legal Mechanisms

A dispute resolution process and patent filing process.

Market Mechanisms

Exchange of goods, services, information, and capital, and establishing prices for these through supply/demand dynamics. Technical Architecture Sophisticated technological infrastructure that allows transdisciplinary learning across space and time.

Social Norms

Agreed-upon standards for what constitutes acceptable behavior – covered in orientation and general university practices.

Participants need access to technology that enables the four forces to regulate behavior, and, just as importantly, must learn its use before the XLP activity.

Through their digital identity, participants must be trained to (among other things):

  • File patents
  • File complaints and sue other entities
  • Defend their legal rights
  • Buy and sell intellectual property and financial and other commodities
  • Publish the products of their learning and their learning outcomes via social (or other)

media

The four forces are all present to an extent in traditional modes of learning, but their respective and collective functions in crowd-learning is relatively minimal, and not systematic. A major reason is the lack of a common digital infrastructure to track market transactions, patent applications, and refutation processes; nor has social media been systematically used to identify and measure cultural norms in a classroom and how they relate to a specific learning scenario.

Therefore, XLP’s activity context is highly technical, and requires big data and other sophisticated technologies and principles to collect, store, process, and analyze data. From a technical perspective, XLP is:

  • A crowd-learning distributed operating system that collects, stores, processes, and analyzes data and generates condensed and refined content with machine and human help.
  • Alearningecologythatcombinesorganicentitieswithdigitalequipmentandprocesses.

XLP leverages open-source technologies, distributed version control systems, and cryptocurrencies to track learners’ individual and collective contributions to the collaborative, collective learning process and learning outcomes.

Computer cycles for collecting, storing, processing, and analyzing data are clearly different from human cycles. Thus enabling many people to simultaneously revise content, for example, requires sophisticated engineering management practices and workflow management techniques, which we generally don’t find in traditional educational settings. However, this technology is becoming increasingly mature and is being leveraged by XLP to become a distributed crowdlearning operating system that provides a learning context – both for individuals and for the crowd – that is very different from that of a traditional educational setting.


Footnotes

<references />


Chapter 7
Back to Content Page
Chapter 9
English version /Chinese version