Push Manifesto
All guides

Oblique Strategies

Technology Primers

Short primers kept for reference: how blockchain works and what its five properties mean, what large language models do and how to prompt them, and the software design principles worth knowing by name.

Updated Sep 11, 202611 min read
technology
blockchain
llm
software-design

Three primers that started as notes for explaining a technology to a non-technical room. They are short on purpose. Each gives you the vocabulary and the shape of the idea so that the real conversation can start from a shared understanding.

Blockchain: Encryption, Immutability, Tokenization, Decentralization, and Distribution🔗

Blockchain is a digital ledger technology that allows for the secure and transparent recording of transactions. It is a decentralized system, meaning it is not controlled by any single entity, and it allows multiple parties to access and contribute to the same information.1

In a blockchain, transactions are grouped into blocks and added to a chain in a linear, chronological order. Each block contains a unique code, called a "hash," that links it to the previous block, creating a chain of blocks that cannot be altered or tampered with. This makes it an ideal technology for recording transactions and maintaining a tamper-proof record of data.

Blockchain technology is often associated with cryptocurrencies like Bitcoin, but it has many other potential uses such as supply chain management, voting systems, digital identity, and smart contracts.2 This technology uses a consensus mechanism, and it is secured by cryptography which makes it difficult to hack or tamper with.

In simple terms, blockchain technology allows multiple parties to share and access a digital ledger of transactions and data, in a decentralized and secure way.

Encryption: Encryption is the process of converting plain text into a coded format that can only be read by someone who has the key to decrypt it. In the context of blockchain, encryption is used to protect the confidentiality of data stored on the blockchain. This ensures that only authorized parties can access and read the data, and it helps to prevent unauthorized access and tampering.

Immutability: Immutability refers to the ability of data to remain unchanged and tamper-proof. In blockchain, immutability is achieved through the use of cryptography and consensus algorithms. Once data is recorded on the blockchain, it cannot be altered or deleted, which makes it ideal for recording transactions and maintaining a tamper-proof record of data.

Tokenization: Tokenization is the process of converting real-world assets into digital tokens that can be traded and exchanged on a blockchain platform. This can include assets such as real estate, art, and commodities, and it can provide a more efficient and secure way of trading and managing these assets.

Decentralization: Decentralization refers to the distribution of power and control across a network of nodes, rather than a central authority. In the blockchain, decentralization is achieved through the use of distributed ledger technology, which allows for a network of nodes to maintain and validate the data stored on the blockchain. This eliminates the need for a central authority and increases the security and resilience of the network.

Distribution: Distribution refers to the ability to share and disseminate data and information across a network. In the blockchain, distribution is achieved through the use of a peer-to-peer network, which allows for the sharing of data and information across a decentralized network of nodes. This can increase the availability and accessibility of data, and it can also increase the security and resilience of the network.

All of the above features can be applied in the context of blockchain technology and are used to build decentralized and secure platforms, to secure and manage data, assets, and transactions, and to ensure that the information in the blockchain is accurate and tamper-proof.

Large Language Models (LLMs)🔗

Introduction🔗

Large Language Models (LLMs) are advanced machine learning models that are designed to understand and generate human language. They are trained on vast amounts of text data and can perform a variety of language-related tasks with high accuracy and coherence.3

Capabilities🔗

  1. Text Generation: Producing coherent and contextually relevant text based on a given input.
  2. Translation: Converting text from one language to another while maintaining the original meaning.
  3. Answering Questions: Providing accurate and relevant answers to user queries.
  4. Summarizing Text: Condensing longer texts into shorter summaries that capture the main points.
  5. Text Completion: Predicting and completing unfinished text based on the given context.
  6. Code Generation: Writing code snippets or entire programs based on natural language descriptions.
  7. Content Moderation: Identifying and filtering inappropriate or harmful content.
  8. Searching: Retrieving relevant information from large datasets or knowledge bases.
  9. Sentiment Analysis: Determining the sentiment expressed in a piece of text.
  10. Brainstorming: Generating ideas and suggestions on various topics.
  11. Grammar Checking: Identifying and correcting grammatical errors in text.

Prompting Techniques🔗

  1. Zero-Shot Prompting: Providing a task without prior examples, relying solely on the model's pre-existing knowledge to generate a response.4
  2. One-Shot Prompting: Giving the model one example before the actual task to guide its response.
  3. Few-Shot Prompting: Supplying a few examples before the actual task to help the model understand the desired output.
  4. Chain-of-Thought Prompting: Breaking down complex tasks into intermediate steps to guide the model to a solution.5
  5. Self-Improving Prompt: Allowing the model to reflect on and iteratively refine its own responses.
  6. Instruction-Based Prompting: Using clear and direct instructions to specify the task, format, tone, or content.
  7. Analogical Reasoning Prompt: Leveraging analogies to help the model draw parallels and approach new tasks.
  8. Hybrid Prompting: Combining elements from various prompting techniques for complex or nuanced tasks.

Workflow🔗

  1. Query Formulation: The process starts with the user input or query.
  2. Information Retrieval: A retriever model searches a large dataset or knowledge base for relevant information.
  3. Content Selection: The system filters and ranks the retrieved information to find the most relevant content.
  4. Response Generation: A generator model creates a response using the selected content and the original query.
  5. Refinement and Output: The generated response is refined for coherence and presented to the user.6

Architecture🔗

LLMs are typically based on transformer architectures, which use self-attention mechanisms to process and generate text. They are trained on diverse datasets that encompass a wide range of topics and languages.

Ethical Considerations🔗

  • Bias and Fairness: Ensuring the model does not propagate harmful biases present in the training data.7
  • Privacy: Protecting user data and ensuring it is not inadvertently revealed by the model.
  • Misuse: Preventing the use of LLMs for generating misleading or harmful content.

Future Directions🔗

  • Improved Context Understanding: Enhancing the model's ability to maintain context over longer texts.
  • Efficiency: Reducing the computational resources required for training and deploying LLMs.
  • Multimodal Capabilities: Integrating text with other data types, such as images and audio.

Key models (as first written)🔗

This list dates from the original note and the field has moved on since. It is kept for context.8

  • GPT-3: Developed by OpenAI, known for its high text generation quality.
  • BERT: Developed by Google, good for understanding the context of words in a sentence.
  • T5: A text-to-text transformer model by Google that converts all NLP tasks into a text-to-text format.

Software design principles🔗

  • SOLID is a set of five design principles for object-oriented programming. These principles are intended to make software more maintainable and scalable.9
    • Single Responsibility Principle: This principle states that a class should have one and only one reason to change, meaning that it should have only one responsibility.
    • Open-Close Principle: This principle states that a class should be open for extension but closed for modification. This means that new functionality can be added to the class without modifying its existing code.
    • Liskov Substitution Principle: This principle states that objects of a superclass should be able to be replaced with objects of a subclass without affecting the correctness of the program.
    • Interface Segregation Principle: This principle states that a class should not be forced to implement interfaces it does not use.
    • Dependency Inversion Principle: This principle states that high-level modules should not depend on low-level modules, but both should depend on abstractions.
  • Boy Scout Rule (Clean Code): This principle states that code should be left cleaner than it was found.10
  • Broken Windows Theory: This principle states that small issues left unresolved will lead to more serious issues.11
  • Don't Repeat Yourself: This principle states that code should not be duplicated.
  • Encapsulation: This principle states that the implementation details of a class should be hidden from other classes.
  • Principle of Least Astonishment: This principle states that code should be written in a way that minimizes surprises for the developer.
  • Don't Call Us We Call You: This principle states that classes should not be tightly coupled.12
  • KISS: Keep it simple, stupid. This principle states that code should be as simple as possible.
  • Persistence Ignorance: This principle states that code should not be tightly coupled to a specific storage technology.
  • Separation of Concerns: This principle states that different aspects of a program should be separated and managed independently.13
  • Stable Dependencies: This principle states that the dependencies of a system should be stable and not change frequently.
  • Tell Don't Ask: This principle states that objects should be told to do something, rather than asking them for information and then making decisions based on that information.14
  • You Ain't Gonna Need It (YAGNI): This principle states that code should not be written until it is needed.15
  • Law of Demeter: This principle states that a module should not know about the inner workings of the objects it manipulates.16
  • Loose Coupling: This principle states that classes should be loosely coupled, meaning that they should have as few dependencies on other classes as possible.
  • High Cohesion: This principle states that a module should have a single, well-defined purpose and that all its components should work together to achieve that purpose.

Footnotes🔗

  1. Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic cash system. bitcoin.org/bitcoin.pdf ↩

  2. Szabo, N. (1997). Formalizing and securing relationships on public networks. First Monday, 2(9). doi:10.5210/fm.v2i9.548 ↩

  3. Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł., & Polosukhin, I. (2017). Attention is all you need. Advances in Neural Information Processing Systems, 30. arXiv:1706.03762 ↩

  4. Zero-, one- and few-shot prompting: Brown, T. B., et al. (2020). Language models are few-shot learners. Advances in Neural Information Processing Systems, 33. arXiv:2005.14165 ↩

  5. Wei, J., et al. (2022). Chain-of-thought prompting elicits reasoning in large language models. Advances in Neural Information Processing Systems, 35. arXiv:2201.11903 ↩

  6. This retrieve-then-generate workflow is retrieval-augmented generation: Lewis, P., et al. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. Advances in Neural Information Processing Systems, 33. arXiv:2005.11401 ↩

  7. Bender, E. M., Gebru, T., McMillan-Major, A., & Shmitchell, S. (2021). On the dangers of stochastic parrots: Can language models be too big? Proceedings of FAccT '21, 610–623. doi:10.1145/3442188.3445922 ↩

  8. GPT-3: Brown et al. (2020), above. BERT: Devlin, J., Chang, M.-W., Lee, K., & Toutanova, K. (2019). BERT: Pre-training of deep bidirectional transformers for language understanding. Proceedings of NAACL-HLT 2019, 4171–4186. T5: Raffel, C., et al. (2020). Exploring the limits of transfer learning with a unified text-to-text transformer. Journal of Machine Learning Research, 21(140), 1–67. ↩

  9. Martin, R. C. (2000). Design principles and design patterns. Object Mentor. The SOLID acronym was coined later by Michael Feathers; the principles, and the package principles including Stable Dependencies, are Martin's. Collected in Martin, R. C. (2002). Agile Software Development: Principles, Patterns, and Practices. Prentice Hall. ↩

  10. Martin, R. C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall, chapter 1. ↩

  11. Hunt, A., & Thomas, D. (1999). The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley. Both the broken-windows analogy (section 2) and DRY (section 7) come from here; the analogy itself is from Wilson, J. Q., & Kelling, G. L. (1982). Broken windows. The Atlantic Monthly, 249(3), 29–38. ↩

  12. The Hollywood Principle. Fowler, M. (2005). Inversion of control. martinfowler.com ↩

  13. Dijkstra, E. W. (1974). On the role of scientific thought. EWD447, in Selected Writings on Computing: A Personal Perspective (1982). Springer. The essay names "separation of concerns". ↩

  14. Sharp, A. (1997). Smalltalk by Example: The Developer's Guide. McGraw-Hill. Popularised in Hunt and Thomas's Tell, Don't Ask tips. ↩

  15. Beck, K. (2000). Extreme Programming Explained: Embrace Change. Addison-Wesley. YAGNI is one of the practices of XP. ↩

  16. Lieberherr, K., Holland, I., & Riel, A. (1988). Object-oriented programming: An objective sense of style. OOPSLA '88 Conference Proceedings, 323–334. doi:10.1145/62083.62113 ↩

Technology Primers | Push Manifesto · Push Manifesto