Categories

Glossary

You are here:
< All Topics
  • Account: A key/value store that is “owned” by an account public key.
  • Account (simple) write: A simple write operation to the account data store to a field that is not protected by other ledger dependencies.
  • Active data object: Transactions, accounts, or the states of actively running stateful smart contracts. Every data object has a unique ID (content addressable hash) and is stored in the ledger as a key/value store. 
  • Address: A public key that can be the owner of tokens and also the input or output of transactions.
  • Address identity registry: Links public key ledger addresses uniquely with IDs.
  • Anchor: An anchor is any issuer of an asset token. In the case of P2P lending, this is either a fiat token (i.e. a digital banknote representing a fiat currency like USD) or a debt security.
  • Anonymous credentials: Anonymous credentials allow a user to show that he has certain credentials without revealing any additional information.
  • Anti-money laundering (AML): The purpose of the AML rules is to help detect and report suspicious activity including the predicate offenses to money laundering and terrorist financing, such as securities fraud and market manipulation.
  • API layer: The set of Findora modules which provides tools and interfaces allowing end-user applications to interact with the Findora network via service provider/auxiliary nodes
  • Archival node: Nodes that store long term transaction history. They may or may not participate in consensus as validator nodes.
  • Asset policies: Configurable sets of rules which restrict and regulate transactions involving certain tokens
  • Asset policy function: A user-defined pure Boolean function (in smart contract code) that defines an arbitrary custom policy check on any transaction which includes a transfer of a specific asset, to which the asset policy function is tied as its custom policy function.
  • Asset token: A data object declaration stored on the ledger that describes the properties of an asset token class
  • Asset tracer: A field taking a different value depending on the traceability of the asset token type.
  • Asset transfer operation: The native operation used to represent the transfer of an asset on the Findora network.
  • Audit registration proof: Accompanies a credential/identity proof and demonstrates that the complete identity information about the user is registered in the regulator database.
  • Authenticated data structure (ADS): A critical technological primitive that is used in combination with raw storage of ledger data is an ADS (authenticated data structure). An ADS has a short data tag called the state commitment. This state head uniquely commits to all the data items included in the ADS
  • Authenticated encryption: Authenticated encryption is a form of symmetric key encryption that provides confidentiality, integrity, and authenticity assurances on the plaintext.
  • Automated alert system: Deploys automated public auditors that will flag suspicious activity and alert a private auditor to investigate.
  • Balance range proof: A zero-knowledge proof which proves that a balance is within a certain amount; in particular uses Bulletproof circuit proofs to prove a range on balances hidden inside Pedersen commitments
  • Borrower: The entity/individual that receives the loan and makes a legal commitment to repay the loan in predetermined installments with interest.
  • Bloom filter with SMT: Space-efficient representation of an unordered set that allows efficient membership testing
  • Bulletproof: A special zero-knowledge proof, based on new research from Stanford University, providing significant efficiency improvements.
  • Circuit proof: A zero-knowledge proof that an arbitrary computation, expressed as an arithmetic circuit, was performed correctly.
  • Class definition object: Static data stored on the ledger that provide information such as how a custom asset is defined (asset token), a user-defined policy function that can be applied to assets (asset policy), the code for a smart contract program (smart contract code), and the specification of a user credential. 
  • Combiner gadget: For the purpose of confidential transactions, takes as input two pairs each consisting of an asset type and an amount. If the types agree then the gadget outputs a pair of the type and the sum of the amounts. If not then it returns its input.
  • Confidential asset tracers: Used by asset issuers, owners, and regulators to track the details of transactions that are otherwise hidden to the public.
  • Confidential transfer: Transfers that hide the amount that is being sent and/or the asset type.
  • Confidential transfer memo: Memo field containing proofs for confidential transfers.
  • Core validator node: Nodes that participate in consensus and sign and publish the proof of the current ledger state. Standard core validator nodes operate full validator nodes.
  • Counting Bloom filter: Space-efficient representation of an unordered set that allows efficient membership testing and, in addition to basic Bloom filter functionality, deletions.
  • Credential: A type definition used to represent some type of real-world certification, accreditation, or other credentials, such as a credit score, accredited investor status, educational degree, employment salary range, etc.
  • Credential/identity proof: Accompany transaction signatures and demonstrate information about the signer’s identity or credentials.
  • Cryptographic accumulator: Authenticated data structure that allow users to cryptographically commit to a database using a short string.
  • Cryptographic commitment: Commits to a chosen value while keeping it hidden to others, with the ability to reveal the value at a later time.
  • Cryptographic traceable group signatures: Group signatures that can be tracked by the group manager (a regulator), but are anonymous to public viewers
  • Cryptographic hash function: A mathematical algorithm that maps data of arbitrary size to a bit string of a fixed size (a hash/digest) and is designed to be a one-way function
  • Cryptographic selective disclosure credential: User’s information is authenticated in a special way such that users can selectively reveal components of their identities instead of their entire personal/financial profile
  • Custodian bank: May act as an intermediary between investor/lender, and anchor who issues fiat tokens (e.g USD on the Findora network.
  • Data provider node: Nodes which service queries from end-users to ledger data. Standard data provider nodes will operate full non-validator nodes.
  • Delegated write: Grants another account, e.g. third-party service, write access without giving it complete control of the account
  • Digital signature: An unforgeable digital stamp on a specific digital message which can be publicly verified to have been signed by the secret key corresponding to a public key.
  • ElGamal encryption: A public key encryption system over an elliptic curve that encodes ciphertext encryptions of messages as curve points.
  • Fault tolerance: The property that the Findora consensus system continues operating properly in the event of the failure of some of its components.
  • Federated Byzantine agreement system (FBAS): A consensus system in which each node chooses its quorum slices, thus allowing for more open membership and decentralized control.
  • Financial passports: Aggregates information about a user, such as a user’s accreditation status, financial identity, credit rating, AML whitelisting, etc.; the technology utilizes selective disclosure credentials which allow users to selectively disclose pieces of information
  • Full non-validator node: Nodes that do not vote on transactions but verify all transactions and participate in ledger storage.
  • Full validator node: Nodes which store recent ledger state, i.e. accounts/UTXOs/smart contract states, and recent history of updates. Full validator nodes must offer high-performance processing of transactions as they participate in consensus.
  • Gateway server node: Nodes which initially filter, process, and broadcast transactions to the network validator nodes. Standard gateway server nodes will operate full non-validator nodes.
  • Group signatures: Enable a participant to sign on behalf of a group of users without revealing which member of the group signed.
  • Guarantor: A party appointed by the borrower to repay the loan in case the borrower defaults.
  • Hash function: Takes an arbitrary length input string and outputs a short, deterministic, random-looking digest
  • Homomorphic commitments (Pedersen): Pedersen commitments are additively homomorphic commitments such that, given two commitments, it is easy to create a commitment of the sum of the committed values.
  • Homomorphic public-key encryption (ElGamal): ElGamal homomorphic encryption is a public-key encryption scheme with the additional property that it is possible to do additive computation on encrypted values.
  • Indexed data objects: Refer to data that is indexed in a special way to serve an additional functional role, such as the UTXO set, address identity registry, and used ID set. 
  • Initial synchronization time: Synchronization time for a new node joining the system as a full/light/gateway node
  • Investor/lender: the entity that provides a cash loan to a borrower and ultimately collects interests and principal on the loan.
  • Join-split proof: Ensures that for each asset the sum of the output amounts is equal to the sum of the input amounts.
  • Know your customer (KYC): Know your customer is a compliance process that is a part of AML.
  • Ledger state: Includes account state, smart contract state, and definitions of static data objects (asset token definitions, smart contract program definitions, credentials & policies etc), and confirmed transactions.
  • Ledger state head: The ADS state head for the ledger state.
  • Light non-validator node: Nodes that do not vote or verify transactions, but synchronize local data with Findora ledger state, issue transactions, perform audit functions
  • Light validator nodes: Participate in consensus but do not participate heavily in storage.
  • Linear secret sharing: Enables a fine-grained distribution of control over cryptographic secrets.
  • Load balancing: Improves the distribution of workloads across multiple computing resources, such as computers, a computer cluster, network links, central processing units, or disk drives.
  • Locally invalid transaction: A transaction that is malformed, incorrectly references current state, or conflicts with confirmed transactions.
  • Main ledger: A public append-only database of financial records, including transactions, accounts, and contracts, that all nodes in the network can access and agree on
  • Manager/Operator: A lending platform information intermediary that provides services such as information collection, information disclosure, credit evaluation, information exchange, and loan matching for direct loans between borrowers and lenders
  • Membership witness: A short proof that a given data item is contained in the ADS, and may include additional information about its position in the ADS.
  • Memo: Additional information required for transaction validity.
  • Merkle tree: A commitment to an ordered list. Used for efficient (logarithmic time) integrity checks on individual items in an ordered list.
  • Metadata: Additional data stored on the ledger such as the ledger state head, UTXO index head, and transaction log head. These are used to help with consensus, more efficient transaction validation, and efficient verification of ledger data authenticity.
  • Mixing services: A service that provides privacy by making it more difficult to link transactions. Multiple users will use the mixing service to combine their transactions such that it is impossible to determine which user sent to whom.
  • Multisignature address: Collection of public keys aggregated into a single address with configurable weights on each key and a specified threshold required for the validity of any.
  • Network availability: The property of a network that queries to nodes always return some result.
  • Network consistency: The property of a network that queries to nodes always returns the most recent and accurate state of the system.
  • Network resilience/partition tolerance: The ability of the network to continue functioning in the event that arbitrary messages between nodes are dropped and one set of nodes cannot communicate with other nodes.
  • Node management system: A software tool for managing a Findora node, interacting with nodes in the network, and understanding properties of the network.
  • Nonce: A value that is only used once, often generated randomly.
  • Pedersen commitment: A point C on an elliptic curve that is cryptographically binding to a data message m, but completely hides the message.
  • Pedersen commitment range proof: A zero-knowledge proof that a curve point C is a Pedersen commitment to an integer value in some range.
  • Pedersen commitment equality proof: A zero-knowledge proof that two distinct curve points C1 and C2 are both Pedersen commitments to the same integer value m.
  • Pedersen-ElGamal equality proof: A zero-knowledge proof that an ElGamal ciphertext encrypts the same value as a Pedersen commitment.
  • Permutation proof: A proof that two lists contain the same elements, i.e. that the lists are permutations of each other.
  • Policies: A special case of a smart contract that attaches terms to specific asset tokens, and regulates the transfer of these assets with Boolean policies.
  • Practical Byzantine Fault Tolerance: Consensus protocol between a set of nodes that tolerates Byzantine faults (malicious nodes)
  • Proof of liquidity: Dynamically indicates if the available current assets of an entity exceed its total current liabilities (near-term accounts payables, short-term debts, etc.).
  • Proof of proper fee: Proves that the fee amount is equal to x% of the confidential payment value without revealing this value. 
  • Proof of solvency: Demonstrates that the value of asset-backed tokens owned by the platform exceeds its liabilities to consumers
  • Proof of timely repayment of loans: A proof that specific loans issued on the Findora ledger have been repaid, timely, and in full.
  • Proof of whitelisted asset: A proof that a (confidential) asset token purchased by a fund is on a whitelist of approved assets.
  • Public audit function: Audit methods that any public user of the system can verify on their own without needing to trust a regulator or central authority.
  • Public key encryption: Asymmetric cryptographic system that uses paired public and private keys to secure data communication.
  • Quorum slices: Technical term for the set of other validators that each validator trusts.
  • Resynchronization time: The amount of time it takes for an offline node to be fully synchronized with the Findora ledger state.
  • Ring signatures: Similar to group signatures in that a user can sign on behalf of a ring of people; however, anonymity is non-revocable, and there is no additional setup required.
  • RSA accumulator: Commitment to an unordered set of items with highly efficient, constant size membership witnesses.
  • Selectively disclosable identity: An identity form signed in a special way by an identity provider which enables the user to selectively reveal information from the verified form.
  • Sentry node: A node that probes the network and triggers alerts that immediately notify regulators about any suspicious or non-compliant activity.
  • Service layer providers: Auditors, anchors, data providers, and auxiliary servers.
  • Sigma protocols: Zero-knowledge proofs that work well for proving algebraic statements about Pedersen commitments or ElGamal encryption.
  • Smart assets: A special case of a smart contract that attaches terms to specific asset tokens, and regulates the transfer of these assets with Boolean policies.
  • Sparse Merkle tree: A representation of a Merkle tree which stores data elements in a sparse way for space efficiency.
  • Thunderella: Consensus protocol as robust as the best synchronous protocols, yet “optimistically” “instantly” confirms transactions.
  • Time bounds: A time window during which the transaction is valid.
  • Token standard: Functions and fields that must be defined in a token asset type.
  • Transaction: A collection of operations, their necessary signatures and proofs, and other restrictions and metadata. A transaction submitted to the Ledger is only committed to the Ledger if all conditions associated with the transaction are validated. A transaction is never partially committed.
  • Transaction batch processing time: The time taken to process each batch, e.g. “block time”.
  • Transaction finality time: The time elapsed between the time of first confirmation and the time that the transaction is considered final.
  • Transaction latency time: The time elapsed between the creation/broadcasting of a transaction and its first confirmation in the network.
  • Transaction throughput: The maximum rate of standard transactions the network can support.
  • Transaction log: All submitted and validated transactions are appended to the transaction log
  • TXO: Transaction output, spent or unspent
  • UTXO: Unspent transaction output
  • UTXO address: A representation of the existing value of some asset.
  • UTXO bitmap: An ordered list of bits that stores one bit per transaction address output in the transaction log.
  • UTXO filter: A collection of counting Bloom filters (CBFs) which records the UTXO set.
  • UTXO head: A state head of an ADS over the UTXO index, implemented as a dynamic self-balancing Merkle tree with inserts/deletes.
  • UTXO set: Consists of all the UTXOs on the Findora ledger in its current state.
  • UTXO set index: Stores the SHA-256 digest of every active UTXO along and a reference to its position in the transaction log.
  • Validator: parties who monitor, verify, and confirm transactions on the Findora network.
  • Variables: May represent addresses, accounts, or integers. Operations use variables together with preconditions for basic smart contract functionality (e.g. “match this loan with any buyer bid for the same terms”).
  • Zero-knowledge proof: A method by which one party, called the prover, can prove to another party, called the verifier, that they know a value x, without conveying any information apart from the fact that they know the value x.

 

Previous Developer questions
Table of Contents