Trust-Smalltalk, AR Network Development Environment


The AR BlockChain and AI Development Framework

Out of stock

Sold By : KaraSpace SKU: 202 Category:


The Trust-Smalltalk development environment is build on top of the core Pharo Smalltalk system, or any other open source Smalltalk system. It requires some changes on the virtual machine, as it introduces principle extensions to the whole Smalltalk paradigm. So it can be seen as a real evolution of the original Smalltalk principles.

As the name implies, the major motivation is to use the principles of blockchain, open source and the user community, to generate absolute trust in complex computer systems.

The development of mainstream augmented reality glasses may be perceived to be only in the far future. But KaraSpace has developed the optical design for the smallest possible form factor, that enables this devices very soon. But the AR concept shows that the second main obstacle for mainstream AR glasses is the lack of trust.

The users will soon realize that mainstream AR glasses bear the horrific potential to monitor every information that enters your mind and every action you perform. Neuronal networks bring all this in a higher context. The world perception will be determined by others and your action can be steered remotely. People, companies and whole countries cannot tolerate to be kept in the dark, what exactly is happening inside the devices.

Fortunately, the blockchain technology has evolved parallel to AR, and the two turned out to be inseparable.

The motivations to use Smalltalk in the first place for the next generation computer front end are as follows:

  • Smalltalk is not only open source, but understandable to normal people.
  • Smalltalk code is readable by common people and not only software engineers.

    reflective system

  • Smalltalk is introspective, so not only the program code but also the life objects and the data structure can be inspected at run time. This is essential to understand programs.
  • Smalltalk is persistent image based that eliminates the need to use and understand different databases
  • Smalltalk is reflective and self-contained, which enables the modification or locking of its own system with its own means. So by implementing blockchain locking on objects, it will reflect on the system itself.
  • Smalltalk is a prototyping environment having brought out our modern Windows GUI itself.
  • Smalltalk means live programming in running programs, eliminating time wasting compiling cycles. This facilitates the programming by the end user.
  • Smalltalk is changeable. The language as well as the development environment can be developed.
  • Smalltalk has automatic garbage collection.
  • Smalltalk is not proprietary to some big corporation and can be used by the millions.
  • Smalltalk has good capabilities to interface into any system, providing an object oriented API to these systems.
  • Smalltalk is a mature system with over 40 years experience.
  • The programmer community is specially experienced over the years and much bigger than for any new designed special purpose language.
  • Smalltalk prevents any low level programming, as it is common with c++ developments. This low level programming disqualifies languages like C to be used for the front end trusted computing layer.

For these reasons a new enhanced Smalltalk system will be the front end operation environment for AR glasses, enabling total transparency about the processes running.

The Smalltalk purely object-oriented paradigm gives further structure to the future development of extremely complex distributed systems.

Trust-Smalltalk (or just TruSt) implements a set of powerful principles on top of the traditional object oriented and image based Smalltalk paradigm:

Second layer blockchain application

second level blockchain

Second level blockchain as smart contract

The System is primarily a second level blockchain and application system for AR in the form of a giant external smart contract. The most prominent example for a first level blockchain application system is Ethereum(L1) and an example application is KryptoKitties(L1). Ethereum implements smart contracts as executable code that people can agree on. But such code can also be placed externally from Ethereum and only the hash value of the code is stored like a certificate on the Ethereum blockchain. This external code (L2) can then be made that it only executes if the connection to the Ethereum network is made and the hash value is confirmed. The External smart contract can now be made very large with different core systems being secured on the first level blockchain. This secure system can now implement a complete second level blockchain infrastructure in open source. The transaction rates are much higher because only the code change relay on the slow Ethereum network. The consensus mechanisms are extremely fast because all the nodes of the network are secured to have the same open source algorithms for consensus. The slow transaction is only the problem of first level blockchain systems, because all their nodes can be programmed and modified by anybody. They must rely on a universal logic for consensus.
The TruSt L2 blockchain can also not be tempered by other tricks, as it performs a combination of proof of stake and cross node hash confirmation. With much fewer nodes involved, instant block confirmation and any possible load balancing tree structure, the transactions can scale into the millions per second for the future virtual reality, that is relying on it.

But besides the blockchain functionality, the system is providing the trust in an open source system that can not be tempered.

Community guarded smart contract

Developer community on the Blockchain

Developer community on the blockchain

Smart contracts are normally defined to be programmed once and then never changed. Because the risk is high to miss out a hidden program error, the code is often audited by external programmers before posted.

To allow changes and bug fixes in the contract, and still keep the intent of the contract unchangeable, it is possible to link a whole organization of a democratic user community and a supporting governance to this contract. This effort is very expansive, and only worthwile for very important and complex smart contracts. For Ethereum, such a programmer community also exists which suggests hardforks.
The Trust-Smalltalk core system functions like a very complex and important smart contract, which can afford to maintain such an organization, which we call a distributed semi-autonomous organization residing also on the blockchain.
Other less important smart contracts may then also be managed under such organizations, if they are established.

The trust in this organization is only as strong as the underlying direct democratic principles that avoid the change of the code by anyone that acts against the interest of the user community.

KaraSpace system governance
Besides the software system and the technical network infrastructure, also the user and programmer community is build up and maintained in an ERP information system. The decision, development and confirmation processes are mapped onto this ERP system, acting as a distributed semi-autonomous organization that will reside on the blockchain in future. This is an integral part of the software system itself, which is the true character of a modern blockchain system.
The governance relies on a larger quantity of token-holding citizens of KaraSpace, to perform democratic control acts. In the meantime the founding team is controlling the rightness of the system.

KaraSpace opperation, contribution and land tokens
Different kinds of tokens must be established to reward contributions to the KaraSpace development, to pay for transactions of the L2 blockchain or to represent virtual assets like the virtual land, which can then be bought and traded.

Organ or multi image orientation
It has proven very successful to use a metaphor from nature to make complex systems naturally understandable for users and programmers alike, and to even learn from biological systems.

The cell-object metaphor is the classical Smalltalk concept of objects that are commonly known to programmers and are summarized as follows:

  • Everything is an object
  • Objects communicate to each other only through messages
  • The variables inside an object can only be accessed through the methods (encapsulation)
  • Method protocols structure the methods
  • Old objects that are not used anymore are cleared by the garbage collection system and not by the programmer
  • All objects reside in an image in memory and can be saved as a whole in a single file on disk.
  • Every object has a class that defines the objet variables and methods, and classes are objects them self
  • Classes are organized in a tree hierarchy from general to special purpose cells, and each class inherits the methods and variables of the so-called superclass

Object and organ oriented

There are may more concepts in the Smalltalk system that are useful to know, but which we can not cover here.


In addition to the cell object metaphor, the new object technology for blockchain trusted AR-Systems adds the organ image metaphor.

Basically the concept of the image being the universe for the resident objects is extended to be an object of a higher order itself. It gets its own worldwide ID and its own protocol to the external world. So a higher order world wide object space of this organs (image-objects) is created.

So the roll of the classical Smalltalk image is extended with the following concepts:

  • The organ (image) is a complex subsystem, but still with standard Smalltalk object concepts like object id, protocols, encapsulation, message sending, garbage collection etc.
  • The object id is valid around the whole world, and so is the object space for organ-objects
  • the organ-objects can be found by the object id through a worldwide distributed object table, providing the location of the organ object
  • So the concept of worldwide objects is introduced (in contrast to the term global, which expands traditionally only within a single image)
  •  The class of an organ is an image on the disk with its initial data state provided by the programmer
  • The instance of an organ is a running image in memory, and has accumulated internal data
  •  There is a separate organ class(image) hierarchy, starting from Pharo-Smalltalk to Trust-Smalltalk and then branching to specialized Systems
  •  Inheritance in this classes(images) does not mean method lookup across images. The idea of inheritance in organs reflects only the dependency to the higher order system and deals with version management. Significant version changes must be adapted manually by the organ subclasses(images)
  • The organ instance is designed to work together with other organs as an Organism
  • Multiple instances of an organ can work in parallel to provide load balancing, data distribution, fault tolerance and the blockchain functionality
  • The stored data within an organ is always persistent, which is achieved by different strategies in the network.
  • The organs use the internal persistent data state as database,  and avoid external databases
  • The organs have access protocols that are more sophisticated then the normal Smalltalk protocol.
  • The organ class, can have different versions over time. For older and newer organs of the same class to work together, or to work together with different organs, the protocols for older version communication are maintained and updates may be enforced by the protocol if necessary.


Object Space Tree Structure

object space tree structure

Distributed object space tree structure



Name Space Tree Structure


Worldwide accessable object ID



Sophisticated protocols for objects and object images
A more sophisticated extension of the notion of method protocols was never the priority until now. With images acting as objects or as a web service, a more strict definition of a protocol is introduced and made available also to normal Objects.

  • Decoration with user rights and layer membership for coding rights
  • Association with broader image wide frameworks like DependendFields, Streaming etc.
  • Providing different protocol versions for older version organ access
  • Access right checking

System browser and inspector integrating the new meta features
also show features like access right, access layers or clusters and sophisticated protocols etc.

First level BlockChain abstraction layer

Bindings to primary level blockchains like Ethereum for easy object oriented access from within Smalltalk
different primary level blockchains may be supported through a common interface






Ethereum certified system stack







Interface to the AR trusted environment







Avoidance of data representation mismatch 







Single image persistency








Image network persistency and distribution








Execution context aware of user and the associated rights

Execution context aware of underlying local or remote image

Integrated web-server providing web services

Integrated Web-HTML server with advanced web interface for access to the image from the web

Three places of user access and modification rights checking
The access right is checked first at the web interface or web services interface. The triggered processes are executed in the context of these users.
The system browsers are modified to only allow the users to interact according to their user rights.
Finally the virtual machine is blocking any violation of user rights in the lowest level.

All system properties decorated optionally with layers or clusters to regulate change access
The core system needs to be protected from manipulation and therefore needs to get restricted write access. Since the Smalltalk objects are traditionally completely free to manipulate by all programmers, considerable changes need to be done to being able to look at all aspects of system manipulation. For trust reasons the system must stay open source and inspectable at any time. It is intended to mentain the praxis for programmers to change and add to the system as long as it does not violate the blockchain-secured core. So system objects need extra fields that hold excess right informations, which we call decorations. This may be enforced through the virtual machine.

  • The compiled methods need decorations that hold the layer specifying the user write access
  • The method dictionaries need decorations and means to prevent method wrapping, method copying or method overwriting in subclasses
  • The classes and metaclasses need decorations to restrict variable adding, deletion, name change etc.
  • The Smalltalk class dictionary needs decorations and means to prevent object wrapping, subclassing etc.
  • Special objects need optional decoration to restrict access
  • Special collection objects need decoration to restrict access

On top of class categories  and packages, the access control layers group access rights
The layers organize access rights, blockchain protection or grand software packages etc.

The system hashing framework aids blockchain certification
Blockchain certification hashing can be obtained on layers, packages, classes, methods or objects.
For highest security, a block can be executed after a fresh system hashing and successful comparison with the blockchain value

Multilingual source code and programming environment
Besides the translation of the programming environment, also a translation system for the source code itself is provided for total transparency and trust. Not only the english speaking population of the world must be able to read and understand the programs, but the whole world must trust the system.

  • The source file and the references from within the compiled method are dropped
  • Compiled methods are always decompiled when viewed so that there can be no hidden discrepancies between source and compiled code.
  • Temporary variable names, comments and structure are also stored in the compiled method object and are inserted separately after decompilation.
  • Method selectors, variable names and comments are provided in different languages, which are translated automatically or with human aid
  • Coding in other languages may also be made possible


More end user friendly system to work with interdependent applications similar like WordPress

Performance tradeoffs like disabling dynamic binding for certain classes 

Separate object image class tree for high level specialized system and application images 

Single or multiple functionality of system or application objectImages

And many more concepts




There are no reviews yet.

Only logged in customers who have purchased this product may leave a review.