※ 본 게시물의 목적, 취지, 이력에 대해선 맨 밑의 비고를 참조(Please go to the bottom to see the purpose, intention, and prior history of this typed reproduction of an original─& incomplete─contribution by the MetaCurrency Project).
제6절 Optimization for Evolution
In the late 1980s, it was already clear that we were going to run out of IPv4 addresses (Internet Protocol version 4). Work began in earnest in 1992 on designing the next version of the Internet Protocol. There was brief experimentation with IPv5, then in 1996 IPv6 was released (which solves many known issues with IPv4). Today, in 2015, we've known about the need for change for almost 30 years, and published the standard to change to almost 20 years ago, but IPv4 is still the basis of over 96% of Interent traffic.
Even though network nodes on IPv4 and IPv6 cannot talk directly to each other, requiring gateways and infrastructure providers to route and bridge both protocols, it looks like they will operate alongside each other for the foreseeable future. Based on the current trajectory, it seems likely that it will have taken us 40 years to upgrade the Internet protocol.
Given the pace of change happening today, and how quickly our needs are evolving, we suggest that it is a big problem to take four decades to move a new protocol even when everyone agrees it is needed. This kind of problem exists not only for communication protocols, but also for operating systems, software, libraries, plugins, and modules which can create a rat's s nest of inconsistencies and compatibility issues.
In Ceptr, we have built versioning and deprecation right into the low-level design of the architecture.
As we've mentioned, Ceptr data is structured as semantic trees. The first branching under the root of a receptor in the Compository is its version. So, when you reference a receptor by its Compository ID, by default you would receive the latest version. However, you can also reference a specific version by a sub-address on that ID. Semantic makers are used to note when versions maintain compatibility with prior protocols and structures or when backward compatibility is broken.
It is also possible for the author of a composition to mark the whole thing (all versions) as decprecated with a forwarding address to a receptor which replaces it. This is important when the next improvement is not simply the new version of the same receptor, but the receptor has been forked to a new composition address or its functions are better performed by another composition altogether.
We see this low-level integration of deprecation and versioning as vital to the evolution of Ceptr itself since we're not assuming we're going to get it all right the first time. We're tackling far too many things at once to be experts at all of it. So, as domain experts start to take interest in Ceptr and contribute better solutions, we expect to update many things (like scape indexing, key management, certificate management, routing algorithms, synchronization methods, GPU processing, and many performance optimizations).
Another example of the importance of this is how it will be used by the Ceptr Network itself. As the network grows, the sharding / routing / distribution algorithms will need to change for better load balancing and to keep each VMHost's share of processing to manageable and sensible levels. We can publish a new version of the CeptrNet receptor, with a schedules changeover date. All connected nodes will be notified of the changeover and have an opportunity to install the new protocols before it goes live. Even if some nodes were offline for a long time and tried to reconnect, other nodes would identify the version of the network protocol they were speaking and send the new protocol upgrade to them using the old version of the protocol (which is still available to them).
Did you know that Wikipedia uses open source tools and shares its databases publicly so that anyone could come up with a way of doing what they do better and would have the means to replace them? In similar manner, we've built in the capacity for competing network protocols to operate in parallel with Ceptr or even replace it altogether if people opted over to that network. This too, is part of optimizing for evolution.
제7절 Trust-Based Agency
(Still to write / expand:)
- No centralized address authority. Self-Generated UUIDs validated via triangulation process of trusted peers “lending” their credibility.
- VMHost UUIDs could also connect to CPUid / MAC addr? And also show ID of agent who spun them up.
- Redefining Freedom. Decreasing degrees of freedom to increase degrees [of] agency.
- Eleutheria: meaning freedom from word roots: arriving (eleu) to where one loves (eran).
제8절 A Strong Immune System
(Still to write / expand:)
- Persistence of identity. Connecting identity to agency. Fingerprinting on agency. [주]†
- Reputation. Erosion of reputation. “SPAM” filtering at network level.
[독자 주]†. 사용자 신분/정체를 지속적으로/집요하게 유지하고, 이것을 사용자의 능동적 행위로 연결하며, 사용자의 각 행위에 지문/증거를 남긴다. 블록체인의 ‘데이터 중심(data-centric)’ vs. 홀로체인의 ‘행위자 중심(agent-centric)’.
※ 비고(This Reader's Remark): 메타커런시 프로젝트(MetaCurrency Project)의 개념과 역사에 대해 탐색해 가면서 아울러 현재와 미래에 걸쳐 동반 탐색자의 출현을 기대하는 공개적인 탐구용 게시물(A personal exploration to learn about something related to the ideas of the MetaCurrency Project and its history, having some hope to find some people interested esp. in Korea though).
- 추적 문서의 위치: The MetaCurrency Project(Ceptr) 또는 https://ceptr.org/revelation/ > 문서명: Ceptr Revelation(자료 형태: 구글문서)
- 최초 탐색: '메타커런시 프로젝트'를 찾아서 1: '보이지 않는 대학 연맹'에 집결된 자료들
- 직전 탐색: 메타커런시 프로젝트를 찾아서 12 - Ceptr Revelation 읽기
#metacurrency-project #ceptr #Serverless-p2p-infrastructure #holochain #kr-dev #kr-economy
꾸욱 들렸다가요
그저 조금씩 읽는 중입니다.