author:

bibliography: example.bib
title: Authors' Instructions: Preparation of Camera-Ready Contributions to SCITEPRESS Proceedings

# INTRODUCTION

Your paper will be part of the conference proceedings therefore we ask that authors follow the guidelines explained in this example in order to achieve the highest quality possible .

Be advised that papers in a technically unsuitable form will be returned for retyping. After returned the manuscript must be appropriately modified.

# MANUSCRIPT PREPARATION

We strongly encourage authors to use this document for the preparation of the camera-ready. Please follow the instructions closely in order to make the volume look as uniform as possible .

Please remember that all the papers must be in English and without orthographic errors.

Do not add any text to the headers (do not set running heads) and footers, not even page numbers, because text will be added electronically.

For a best viewing experience the used font must be Times New Roman, except on special occasions, such as program code .

## Manuscript Setup

The template is composed by a set of 7 files, in the following 2 groups:
To format your paper you will need to copy into your working directory, but NOT edit, the following 4 files:

      - apalike.bst
      - apalike.sty
      - article.cls
      - scitepress.sty

Additionally, you may wish to copy and edit the following 3 example files:

      - example.bib
      - example.tex
      - scitepress.eps

## Page Setup

The paper size must be set to A4 (210x297 mm). The document margins must be the following:

-   Top: 3,3 cm;

-   Bottom: 4,2 cm;

-   Left: 2,6 cm;

-   Right: 2,6 cm.

It is advisable to keep all the given values because any text or material outside the aforementioned margins will not be printed.

## First Section

This section must be in one column.

### Title and Subtitle

Use the command *$\backslash$title* and follow the given structure in "example.tex". The title and subtitle must be with initial letters capitalized (titlecased). The separation between the title and subtitle is done by adding a colon ":" just before the subtitle beginning. In the title or subtitle, words like "is", "or", "then", etc. should not be capitalized unless they are the first word of the title or subtitle. No formulas or special characters of any form or language are allowed in the title or subtitle.

### Authors and Affiliations

Use the command *$\backslash$author* and follow the given structure in "example.tex". Please note that the name of each author must start with its first name.

### Keywords

Use the command *$\backslash$keywords* and follow the given structure in "example.tex". Each paper must have at least one keyword. If more than one is specified, please use a comma as a separator. The sentence must end with a period.

### Abstract

Use the command *$\backslash$abstract* and follow the given structure in "example.tex". Each paper must have an abstract up to 200 words. The sentence must end with a period.

## Second Section

Files "example.tex" and "example.bib" show how to create a paper with a corresponding list of references.

This section must be in two columns.

Each column must be 7,5-centimeter wide with a column spacing of 0,8-centimeter.

The section text must be set to 10-point.

Section, subsection and sub-subsection first paragraph should not have the first line indent.

To remove the paragraph indentation (only necessary for the sections), use the command *$\backslash$noindent* before the paragraph first word.

If you use other style files (.sty) you MUST include them in the final manuscript zip file.

### Section Titles

The heading of a section title should be in all-capitals.

Example: *$\backslash$section{FIRST TITLE}*

### Subsection Titles

The heading of a subsection title must be with initial letters capitalized (titlecased).

Words like "is", "or", "then", etc. should not be capitalized unless they are the first word of the subsection title.

Example: *$\backslash$subsection{First Subtitle}*

### Sub-Subsection Titles

The heading of a sub subsection title should be with initial letters capitalized (titlecased).

Words like "is", "or", "then", etc should not be capitalized unless they are the first word of the sub subsection title.

Example: *$\backslash$subsubsection{First Subsubtitle}*

### Tables

Tables must appear inside the designated margins or they may span the two columns.

Tables in two columns must be positioned at the top or bottom of the page within the given margins. To span a table in two columns please add an asterisk (\*) to the table *begin* and *end* command.

Example: *$\backslash$begin{table\*}*

*$\backslash$end{table\*}*
Tables should be centered and should always have a caption positioned above it. The font size to use is 9-point. No bold or italic font style should be used.

The final sentence of a caption should end with a period.

| Example column 1 | Example column 2 |
|:----------------:|:----------------:|
|  Example text 1  |  Example text 2  |

This caption has one line so it is centered.

| Example column 1 | Example column 2 |
|:----------------:|:----------------:|
|  Example text 1  |  Example text 2  |

This caption has more than one line so it has to be justified.

Please note that the word "Table" is spelled out.

### Figures

Please produce your figures electronically, and integrate them into your document and zip file.

Check that in line drawings, lines are not interrupted and have a constant width. Grids and details within the figures must be clearly readable and may not be written one on top of the other.

Figure resolution should be at least 300 dpi.

Figures must appear inside the designated margins or they may span the two columns.

Figures in two columns must be positioned at the top or bottom of the page within the given margins. To span a figure in two columns please add an asterisk (\*) to the figure *begin* and *end* command.

Example: *$\backslash$begin{figure\*}*

*$\backslash$end{figure\*}*

Figures should be centered and should always have a caption positioned under it. The font size to use is 9-point. No bold or italic font style should be used.

The final sentence of a caption should end with a period.

Please note that the word "Figure" is spelled out.

### Equations

Equations should be placed on a separate line, numbered and centered.
The numbers accorded to equations should appear in consecutive order inside each section or within the contribution, with the number enclosed in brackets and justified to the right, starting with the number 1.

Example:

$$\label{eq1}
    a=b+c$$

### Algorithms and Listings

Algorithms and Listings captions should have font size 9-point, no bold or italic font style should be used and the final sentence of a caption should end with a period. Captions with one line should be centered and if it has more than one line it should be set to justified.

### Program Code

Program listing or program commands in text should be set in typewriter form such as Courier New.

Example of a Computer Program in Pascal:

The text must be aligned to the left and in 9-point type.

### Reference Text and Citations

References and citations should follow the APA (Author, date) System Convention (see the References section in the compiled manuscript). As example you may consider the citation . Besides that, all references should be cited in the text. No numbers with or without brackets should be used to list the references.

References should be set to 9-point. Citations should be 10-point font size.

You may check the structure of "example.bib" before constructing the references.

For more instructions about the references and citations usage please see the appropriate link at the conference website.

# COPYRIGHT FORM

For the mutual benefit and protection of Authors and Publishers, it is necessary that Authors provide formal written Consent to Publish and Transfer of Copyright before publication of the Book. The signed Consent ensures that the publisher has the Author's authorization to publish the Contribution.

The copyright form is located on the authors' reserved area.

The form should be completed and signed by one author on behalf of all the other authors.

# CONCLUSIONS

Please note that ONLY the files required to compile your paper should be submitted. Previous versions or examples MUST be removed from the compilation directory before submission.

We hope you find the information in this template useful in the preparation of your submission.

# ACKNOWLEDGEMENTS

If any, should be placed before the references section without numbering. To do so please use the following command: *$\backslash$section\*{ACKNOWLEDGEMENTS}*

# APPENDIX

If any, the appendix should appear directly after the references without numbering, and not on a new page. To do so please use the following command: *$\backslash$section\*{APPENDIX}*


abstract: The prevalence of Internet of Things (IoTs) allows heterogeneous embedded smart devices to collaboratively provide smart services with or without human intervention. While leveraging the large-scale IoT-based applications like Smart Gird or Smart Cities, IoTs also incur more concerns on privacy and security. Among the top security challenges that IoTs face, access authorization is critical in resource sharing and information protection. One of the weaknesses in today's access control (AC) is the centralized authorization server, which can be the performance bottleneck or the single point of failure. In this paper, BlendCAC, a blockchain-enabled decentralized capability-based AC is proposed for the security of IoTs. The BlendCAC aims at an effective access control processes to devices, services and information in large scale IoT systems. Based on the blockchain network, a capability delegation mechanism is suggested for access permission propagation. A robust identity-based capability token management strategy is proposed, which takes advantage of smart contract for registering, propagation and revocation of the access authorization. In the proposed BlendCAC scheme, IoT devices are their own master to control their resources instead of being supervised by a centralized authority. Implemented and tested on a Raspberry Pi device and on a local private blockchain network, our experimental results demonstrate the feasibility of the proposed BlendCAC approach to offer a decentralized, scalable, lightweight and fine-grained AC solution to IoT systems.
author:
;
;
bibliography: report.bib
title: BlendCAC: A BLockchain-ENabled Decentralized Capability-based Access Control for IoTs

# Introduction

Thanks to the proliferation of the Internet of Things (IoTs), more and more smart devices are connected to the Internet at an unprecedented scale. The prevalence of the IoTs changes human activities by pervasively providing applications and services revolutionizing transportation, healthcare, industrial automation, and emergency response . These capabilities enable both situational awareness (SAW) and information fusion based on uninterrupted, ubiquitous, real-time data flows, which provide essential contextual information for delay-sensitive, mission-critical applications .

While benefiting from the large-scale applications like Smart Gird and Smart Cities, highly connective smart IoT devices with insufficient security enforcement incur more concerns on security and privacy. Security issues, such as privacy, authentication, access control, system configuration, information storage and management, are among the top challenges in today's IoT environment .

One of the top security concerns that IoTs face is access control (AC). Access authorization is particularly critical in resource and information protection. Conventional AC approaches, such as the Access Control List (ACL), the Role-based Access Control (RBAC) and the Attribute-based Access Control (ABAC), have been widely used in IT systems. However, they are not able to provide a scalable, manageable and efficient mechanism to meet new challenges raised by IoT networks:

1.  *Scalability*: The fast growing number of devices and services also pose increasing management workload to AC systems. AC strategies are expected to be able to handle the scalability problem resulting from the large scale IoT networks.

2.  *Heterogeneity*: IoT systems normally integrate heterogeneous computing nodes and other physical devices with variant underlying technologies or in different application domains, and each domain or platform has its own specific requirements for identity authentication and authorization policy enforcement.

3.  *Causality*: The traditional RBAC and ABAC systems envisage planned and long-lived patterns, while the IoT world is mainly characterized by short-lived, with causal and/or spontaneous interactions , in which the AC scheme is required to dynamically respond.

4.  *Lightweight*: IoT devices are usually resource-constrained, which implies the lack of capability to support computing intensive tasks or large storage required applications. meanwhile, the smart devices connect to each other by low power and lossy networks. Consequently the AC protocols should be lightweight and not impose significant overhead on devices and communication networks.

The extraordinary large number of devices with heterogeneity and dynamics necessitate a more scalable, flexible and lightweight AC mechanism for IoT networks. In addition, a majority of the AC solutions rely on centralized authorities. Although the delegation mechanism helps migrate certain intelligence from the centralized cloud server to a near-site fog or edge network, the power of policy decision making and identity management is exclusively located in the cloud center. IoT networks need a new AC framework that provides decentralized authentication and authorization schemes in trustless application network environments, such that intelligence could be diffused among large number of distributed edge devices.

While being well-known as the fundamental protocol of Bitcoin , the first digital currency, the blockchain protocol has been recognized as the potential to revolutionize the fundamentals of IT technology because of its many attractive features and characteristics such as supporting decentralization and anonymity maintenance . In this paper, a *BLockchain-ENabled, Decentralized, Capability-based Access Control* (BlendCAC) scheme is proposed to enhance the security of IoTs. It provides a scalable, fine-grained, and lightweight AC solution to protect smart devices, services and information in IoT networks. An identity-based capability token management strategy is presented and the authorization delegation mechanism is illustrated. A capability-based access validation process is implemented on service providers that integrate situational awareness (SAW) and customized contextualized conditions. Experimental results demonstrate the feasibility and effectiveness of the proposed AC scheme.

The major contributions of this work are:

-   A complete architecture of capability-based authorization is proposed, which includes capability management, delegation propagation, and access right validation.

-   A concept-proof prototype based on smart contracts is implemented and deployed on a local private blockchain network.

-   A comprehensive experimental study has been conducted that compares the proposed BlendCAC scheme with the well-known RBAC and ABAC models. The experimental results validate the feasibility of the BlendCAC scheme in IoT environments without introducing significant overhead.

The remainder of this paper is organized as follows: Section analyzes and reviews the state of the art research in access control for IoT systems. Section illustrates the details of the proposed BlendCAC system. Beside the implementation of the proof-of-concept prototype, Section reports an extensive experimental study using test scenarios that are run on both resource-constrained and non-resource-constrained devices. Finally, a summary wraps up this paper in Section .

# Background Knowledge and Related Work

## Access Control in IoTs

Technologies for authentication and authorization of access to certain resources or services are among the main elements to protect the security and privacy for IoT devices . As a fundamental mechanism to enable security in computer systems, AC is the process that decides who is authorized to have what communication rights on which objects with respect to some security models and policies . An effective AC system should satisfy the main security requirements, such as confidentiality, integrity, and availability. However, recently raised security and privacy issues in the era of IoTs require that AC systems should be built on principals of high scalability, flexibility, lightweight and causality.

There are various AC methods and solutions with different objectives proposed to address security challenges in IoTs. The Role-Based Access Control (RBAC) model provides a framework that species user access authorization to resources based on roles, and supports principals such as least privilege, partition of administrative functions and separation of duties . However, a pure RBAC model presents a role explosion problem, which is inappropriate to implement security policies that require interpreting complex and ambiguous IoT scenarios. The RBAC model implemented on IoTs adopts a Web of Things (WoTs) approach to implement AC policies on the smart objects via the web service , and the RBAC model was extended by introducing context constraints to consider contextual awareness in AC decisions . However, those proposals are not able to clearly specify the fine-grained AC on variant resources or services, like the mapping of the role notion and device-to-device communication.

To address the weaknesses of RBAC model in a highly distributed network environment, an Attribute-based Access Control (ABAC) is introduced in IoT networks to reduce the number of rules resulting from role explosion. In ABAC the AC policies are defined through directly associating attributes with subjects. An efficient authentication and ABAC based authorization scheme for the perception layer of IoTs have been proposed . Based on user attribute certificates, an access right is granted by AC authority to ensure fine-grained access control. However, specifying a consistent definition of the attributes within a domain or across different domains could significantly increase effort and complexity on policy management as the number of devices grow, and hence, the attribute-based proposal is not suitable for large scale distributed IoT networks.

Due to drawbacks that exist in traditional access control models such as RBAC and ABAC, the requirements imposed by IoT scenarios cannot be satisfied. Given many great advantages from an IoT perspective, such as scalability, flexibility, distributed, user-driven, IoT systems can support delegation and revocation. Capability-based access control approaches have been considered a promising solution to IoTs. The Access Control Matrix (ACM) model represents a good conceptualization of authorizations by providing a framework for describing discretionary access control (DAC) . As two implementations of ACM, Access Control List (ACL) and Capability are widely used in authorization system. In the ACL model, each object is associated with an access control list that saves the subjects and their access rights for the objects.

The ACL is a centralized approach to support administrative activities with better traceability by implementing AC strategies on cloud servers . However, as the number of subjects and resources increases, confused duty problems are identified in ACL and access rules become much more complex to manage. Due to the centralized management property, ACL cannot provide multiple levels of granularity, is not scalable and is vulnerable to single point of failure. Meanwhile, in the capability model, each subject is associated with a capability list that represents its access rights to all concerned objects. The CapAC has been implemented in many large scale IoT-based projects, like IoT@Work .

Although capability-based methods have been used as a feature in many access control solutions for the IoT-based applications, applying the original concept of capability-based access control model in IoT network has raised several issues, like capability propagation and revocation . To tackle these challenges, a Secure Identity-Based Capability (SICAP) System is proposed, which enables the monitoring, mediating, and recording of capability propagations to enforce security policies as well as achieving rapid revocation capability by using an exception list . However, the centralized access control server (ACS) becomes the performance bottleneck of the system, and the author didn't provide a clear illustration on security policy used in capability generation and propagation, neither was the context information in making authorization decision considered.

To enable contextual awareness in federated IoTs, an authorization delegation method is proposed based on a Capability-based Context-Aware Access Control (CCAAC) model . By introducing a delegation mechanism to capability generation and propagation process, the CCAAC model shows great advantages to address scalability and heterogeneity issues in IoT networks. Given the requirement that a prior knowledge of the trust relationship among domains in federated IoTs must be established, however, the proposed approach is not suitable universally for all IoT application scenarios. Inspired by the SUN DIGITAL ECOSYSTEM ENVIRONMENT project , a capability-based access control (CapAC) model was proposed that adopted a centralized approach for managing access control policy . However, the proposed CapAC scheme depended on a centralized authority and did not consider the lightweight requirement at the smart device side. To address the limitations in CapAC, a Distributed Capability-based Access Control (DCapAC) model was proposed, which was directly deployed on resource-constrained devices . The DCapAC allows smart devices to autonomously make decisions on access rights based on authorization policy, and it shows advantages in scalability and interoperability. However, capability revocation management and delegation were not discussed, neither were the granularity and context-awareness considered.

## Blockchain and Smart Contract

The blockchain is the fundamental framework of Bitcoin , which was introduced by Nakamoto in 2008. The blockchain is the public ledger that allows the data be recorded, stored and updated distributively. By its nature, the blockchain is a decentralized architecture such that does not rely on a centralized authority anymore. The transactions are approved and recorded in blocks by miners, and the blocks are appended to the blockchain in a chronological order. Blockchain uses consensus mechanism to maintain the sanctity of the data recorded on the blocks. Thanks to the "trustless" proof mechanism enforced through mining task on miners across network, users can trust the system of the public ledger stored worldwide on many different decentralized nodes maintained by "miner-accountants," as opposed to having to establish and maintain trust with the transaction counter-party or a third-party intermediary . Blockchain is the ideal architecture to ensure distributed transactions between all participants in a trustless environment.

Because of many attractive characteristics, blockchain technology has been investigated to offer a decentralized AC scheme in trustless network environments. A blockchain based AC is proposed to publish AC policy and to allow distributed transfer access right among users on bitcoin network . The proposal allows distributed auditability, preventing a third party from fraudulently denying the rights granted by an enforceable policy. However, the solution still rely on an external centralized policy database to fetch access right given the links stored in the blockchain, and the experimental results are not provided. Based on blockchain technology, FairAccess is proposed to offer a fully decentralized pseudonymous and privacy preserving authorization management framework for IoTs . In FairAccess, AC policies are enclosed in new types of transactions that are used to grant, get, delegate, and revoke access. However, the scripting language used in Bitcoin allows to transcode two types of AC policies, so that the proposed framework cannot support more complex and granular access control model.

Blockchain has shown its success in decentralization of currency and payments, like Bitcoin. Currently designing a programmable money and contracts, which support variety of customized transaction types become a trend to extend blockchain application beyond cryptocurrency. Smart contract, which emerges from the smart property, is a method of using blockchain to achieve agreement among parties, as opposed to rely on third parties for maintaining a trust relationship. By using cryptographic and other security mechanisms, smart contract combines protocols with user interfaces to formalize and secure relationships over computer networks. Smart contract is essential a collection of defined instructions and data that have been recorded at a specific address of blockchain. Through encapsulating operational logic as a bytecode and performing Turing complete computation on distributed miners, a smart contract allows user to transcode more complex business models as new types of transactions on a blockchain network. Smart contract provides a promising solution to implement more flexible and fine-grained AC models on blockchain networks.

# BlendCAC: a BLockchain-ENabled Decentralized CapAC

In order to address the issues discussed in Section , the authors recently proposed a Federated Capability-based Access Control model (FedCAC) . FedCAC addresses scalability, granularity, and dynamicity challenges in access control strategy for IoTs. Through delegating part of the identify authentication and authorization task to domain delegator, workload of the centralized policy decision making center (PDC) is reduced. Migrating some processing validation tasks to local devices helps the FedCAC to be lighter and context-awareness enabled. Involving smart objects in access right authorization process allows device-to-device communication, which implies better scalability and interoperability in IoT network environment. However, it is essentially still a centralized AC scheme, such that weaknesses include being the single-point of failure and performance bottleneck, are still not solved.

Inspired by the smart contract and blockchain technology, a decentralized capability-based access control framework for IoTs, called BlendCAC, is proposed in this paper, and a prototype of proposal has been implemented in a physical IoT network environment to verify the efficiency and effectiveness. The next subsection provides a comprehensive system design of BlendCAC framework. Unlike the approaches discussed above, BlendCAC, effectively provides scalability, granularity, and dynamicity of AC strategies for IoTs. Through encapsulating AC policies into a Smart Contract, which is deployed across the blockchain network, users are the master of their own data or devices instead of being supervised or controlled by a third party authority. Enforcing authorization and access right verification among large number of distributed edge devices allows more coordination on edge networks.

## System Architecture of BlendCAC

Figure illustrates the proposed BlendCAC system architecture, which intends to function in a scenario including two isolated IoT-based service domains without pre-establishing a trust relationship. In each domain, the domain owner, who has the ownership of devices, enforces predefined security policies to manage domain related devices and services. Operation and communication mode is listed as follow:

1.  *Registration*: All entities must create at least one main account defined by a pair of keys to join the blockchain network. Each account is indexed by its address that is derived from his/her own public key. In our scenario, the domain owner maintains a local profile database that provides identity authentication and management. Once the identity information related to users or IoT devices is verified, the profile of each registered entity is created by using his/her address for authentication process when an access right request happens. As a result, the domain owners are able to define authorization policies and perform decision-making to directly control their own devices or resources instead of depending on third parties.

2.  *Smart Contract Deployment*: A smart contract, which manages capability tokens, must be developed and deployed on the blockchain network by the domain owner. Thanks to cryptographic and security mechanisms provided by blockchain network, smart contracts can secure any algorithmically specifiable protocols and relationships from malicious interference by third parties under trustless network environment. After synchronizing the blochchain data, all nodes could access all transactions and recent state of each smart contract by referring local chain data. Each node interacts with the smart contract through the provided contract address and the RPC interface.

3.  *Capability Propagation*: To successfully access services or resources at service providers, an entity initially sends an access right request to the domain owner to get a capability token. Given the registered entity information established in the profile database, a policy decision making module evaluates the access request by enforcing the predefined authorization policies. If the access request is granted, the domain owner issues the capability token encoded the access right, then launches a transaction to update the token data in the smart contract. After the transaction has been approved and recorded in a new block, the domain owner notifies the entity with a smart contract address for the querying token data. Otherwise, the access right request is rejected.

4.  *Authorization Validation*: The authorization validation process is performed at the local service providers on receiving a service request from the entity. Through regularly synchronizing the local chain data with the blockchain network, a domain owner just simply checks the current state of the contract in the local chain to get a capability token associated with the entity's address. Considering the capability token validation and access authorization process result, if the access right policies and conditional constraints are satisfied, the service provider grants the access request and offers services to the requester. Otherwise, the service request is denied.

To enable a scalable, distributed and fine-grained AC scheme for IoT networks, the proposed BlendCAC is focused on three issues: the identity-based capability management, the access right authorization and the privilege delegation.

## Capability Token Structure

In the BlendCAC system, the entities are categorized as subjects and objects. *Subjects* are defined as entities who request a service from the service providers, while *objects* are referred to entities who offer the resources or services. Entities could be either human beings or smart devices. In the profile database, all registered entities are associated with a globally unique Virtual Identity (VID), which is used as the prime key for identifying entities' profile information. As each entity has at least one main account indexed by its address in the blockchain network, the blockchain is used to represent the VID for profiling register entities.

In general, the capability specifies which subject can access resources of a target object by associating subject, object, actions and condition constraints. The identity-based capability structure is defined as follows: $$\label{eq:ICap}
ICap = f(VID_{S}, VID_{O}, D, AR, C)$$

-   $f$: a one-way hash mapping function;

-   $VID_{S}$: the virtual ID of a subject that requests an access to a service or resource;

-   $VID_{O}$: the virtual ID of an object that provides a service or resource;

-   $D$: a set of delegation right, e.g. delegatee and delegation depth;

-   $AR$: a set of access right for actions, e.g. read, write, execute; and

-   $C$: a set of context awareness information, such as time, location.

In the BlendCAC system, an $AR$ is defined as the access right set. For example, the $AR$ can be $\{Read\}$, $\{Write\}$, $\{Read; Write\}$, or $\{NULL\}$. If $AR=\{NULL\}$, the operation conducted on the resource is not allowed. $C$ is defined as a context constraints set, like $C=\{C1, C2\}$ or $C=\{NULL\}$. If $C=\{NULL\}$, no context constraint is considered in the access right validation process. The delegation privilege is defined in set $D$ including *delegatee* and *delegation depth*. The *delegatee* is defined as an array to queue the delegated entity's address, and the *delegation depth* specifies the maximum delegation operations.

## Capability-based Access Right Authorization

Given the defined BlendCAC structure, the capability token structure and the related operations are transcoded to a smart contract and deployed on the blockchain network, while the access right authorization is implemented as a policy-based decision making service running by the domain owner. As shown by Fig. , a comprehensive capability-based access right authorization procedure consists of four steps: capability generation, access right validation, capability delegation and revocation.

1.  *Capability Generation*: As one type of meta data to represent the access right, the capability $ICap$ could be generated by associating a VID with an AR, thus the $ICap$ has the identified property to prevent forgery. After receiving access request from user, the domain owner generates capability token based on predefined access control policy, and launches transactions to save a new token data to a smart contract. A large number of $ICap$ is grouped into the capability pools on smart contract, which could be proofed and synchronized among the nodes across the blockchain network.

2.  *Access Right Validation*: After receiving the service request from a subject, the service provider first fetches the capability token from the smart contract by using the subject's address, then makes decision whether or not to grant an access to the service according to the local access control policy. Implementing access right validation at the local service provider allows smart objects to be involved in the AC decision making task, which is suitable to offer a flexible and fine-grained AC service in IoT networks.

3.  *Capability Delegation*: In our proposal, the capability delegation mechanism is implemented by configuring delegation set $D$ in the $ICap$. As the smart contract has received an update token transaction from the user, it checks the set $D$ to validate the delegation right. If the value of *delegation depth* is more than the count of elements in *delegatee*, the user could delegate his/her capability token to other entity by appending the target address to *delegatee*. Otherwise, the capability delegation request is rejected. For each successful delegation transaction, the length of queue *delegatee* increases by $1$ until reaches the limitation defined by the delegation depth.

4.  *Capability Revocation*: The capability revocation considers two scenarios: delegation right $D$ revocation and $ICap$ revocation. In our proposal, only the domain owner is allowed to perform revocation operation on a smart contract. In the delegation right revocation process, the domain owner could remove the addresses from *delegatee* to revoke the delegated access right for certain specific entities. In case of $ICap$ revocation, through changing *delegation depth* to zero or clearing the $AR$, the capability token becomes unavailable to all associated entities.

# Implementation and Experimental Results

A concept-proof prototype system has been implemented on a real private Ethereum blockchain network environment. Compared with other open blockchain platform, like Bitcoin and Hyperledger, Ethereum has a more matured ecosystem and is designed to be more adaptable and flexible for development of smart contract and business logic . The proposed BlendCAC model has been transcoded to a smart contract using Solidity , which is a contract-oriented, high-level language for implementing smart contracts. The access authorization and validation policy is enforced as a web service application based on the Flask framework using Python. The Flask is a micro-framework for Python based on Werkzeug, Jinja 2 and good intentions. The lightweight and extensible micro architectures make the Flask a preferable web solution on resource constrained IoT devices.

In order to evaluate the performance and the overhead of our BlendCAC scheme, two benchmark models, RBAC and ABAC, are also implemented on the experimental web service system. All transcoded access control models have the similar data structure in smart contract except authorization representation. In RBAC based smart contract, authorization is defined as the approach to bridge the relationship between user and permission, while RBAC based smart contract uses user's attributes as representative format for authorization. Both the RBAC and ABAC need a local database, either to maintain the user-role-permission or to manage the attribute-permission policy for authorization validation process, the profiles and policy rules management are developed by using an embedded SQL database engine, called SQLite. The lower memory and computation cost make the SQLite an ideal database solution to resource constrained system, like Raspberry Pi.

## Environmental Setup

The mining task is performed on a system with stronger computing power, like a laptop or a desktop. Two miners are deployed on a laptop, of which the configuration is as follows: the processor is 2.3 GHz Intel Core i7 (8 cores), the RAM memory is 16 GB and the operating system is Ubuntu 16.04. And other four miners are distributed to four desktops which are empowered with the Ubuntu 16.04 OS, 3 GHz Intel Core TM (2 cores) processor and 4 GB memory. Each miner uses two CPU cores for mining. The IoT devices are two Raspberry PI 3 Model B with the configuration as follows: 1.2GHz 64-bit quad-core ARMv8 CPU, the memory is 1GB LPDDR2-900 SDRAM and the operation system is Raspbian based on the Linux kernel. Unfortunately, the Raspberry PI is not powerful enough to function as a miner, so two Raspberry Pi worked as nodes to join the private blockchain without mining. All devices use Go-Ethereum as the client application to work on the blockchain network.

## Performance Evaluation

In the test scenario, two Raspberry Pi 3 devices are adopted to play the roles of the client and the service provider respectively. To measure the general cost incurred by the proposed BlendCAC scheme both on the IoT devices' processing time and the network communication delay, 50 test runs have been conducted based on the proposed test scenario, where the client sends a data query request to the server for an access permission. This test scenario is based on an assumption that the subject has a valid capability token when it performs the action. Therefore, all steps of authorization validation must be processed on the server side so that the maximum latency value is computed.

### Computational Overhead

According to the results shown in Fig. , the average total delay time required by the BlendCAC operation of retrieving data from the client to server is 243 ms, which is almost the same as RBAC or ABAC does. The total delay includes the round trip time (RTT), time for querying capability data from the smart contract, time for parsing JSON data from the request, and time for access right validation. The token processing task is mainly responsible for fetching token data from the smart contract and introduces the highest workload among the authorization operation stages. Owing to the fact that encapsulating user-role relationship in the smart contract requires less data than the capability or attributes does, the RBAC incurred less computational cost than what BlendCAC and ABAC did in token processing stage. As the most computing intensive stage, the execution time of token processing is about 210 ms, which is accounted for almost 86% of the entire process time.

The entire authorization process is divided into two steps, token validation and authorization verification, where the average time of the authorization process is about 0.86 ms (0.12 ms + 0.74 ms). Compared with token validation process, which only simply checks the token valid status, the authorization verification process requires more computational power to enforce the local access control policies. Although the similarity in token data structure allows all the three access control models have almost the same time in the token validation stage, the BlendCAC outperforms the RBAC and ABAC in authorization verification. Since both the RBAC and ABAC needs a database to either manage user-role-permission relationship or maintain attributes-permission rules, which inevitably incurs time consuming on searching rules in database. In our experimental study, the RBAC (2.47 ms) and ABAC (2.07 ms) have much higher processing time than BlendCAC (0.74 ms).

### Communication Overhead

Owing to the high overhead introduced by querying token data from the smart contract in token processing stage, a token data caching solution is introduced in the BlendCAC system to reduce network latency. When the client sends a service request to the server, the service side extracts cached token data from the local storage to valid authorization. The service providers regularly update cached token data by checking smart contract status. The token synchronization time is in consistence with block generation time, which is about 15 seconds in the Ethereum blockchain network. Simulating a regular service request allows us to measure how long it takes for the client to send a request and retrieve the data from the server.

Figure shows the overall network latency incurred and compares the execution time of the BlendCAC with RBAC, ABAC and a benchmark without any access control enforcement. At the beginning, a long delay is observed in the first service request scenario, in which service provider communicated with the smart contract and cached the token data. However, through processing the local cached token data for authorization validation, the network latency decreases quickly and becomes stable at a low level during the subsequent service requests. The benchmark without access control enforcement takes an average of 31 ms for fetching requested data versus that the BlendCAC consumes on average of 36 ms. It means that the proposed BlendCAC scheme only introduces about 5 ms extra latency. The overhead in terms of delay is trivial. As shown by Fig. , the BlendCAC also has lower latency than RBAC and ABAC in most period of time. In addition, unlike RBAC and ABAC, which rely on the local policy database as intermediate to valid access right, encoding access right directly in capability token makes the BlendCAC more scalable and flexible in the large scale IoT networks.

As the experimental results show, the proposed BlendCAC scheme introduced a small amount of overhead, both at the network layer and the local device layer. To measure general network latency of inter-domain communication, HTTP is executed on the same testbed to simulate a regular transaction, like connects, sends a request and retrieves the reply. Compared with calculated average network latency that is about 300 ms, the trade-off in the proposed BlendCAC is acceptable for the network environments by only incurring 5 ms latency (no more than 2%). In addition, the test scenarios are based on Raspberry Pi devices, which belongs to a type of simple board computer (SBC) with limited computation power and memory space. It is reasonable to expect a better performance when the BlendCAC scheme is implemented on more powerful smart devices, like a smart phone. Although synchronizing cached token data with the smart contract requires more computational resource, the transactions of querying smart contract status are regularly launched by the service providers in a separate service thread rather than being called in each service request, so that network overhead over service request communication is greatly reduced to improve QoS requirement.

## Discussions

The experimental results demonstrate that the proposed BlendCAC strategy is effective and efficient to protecting the IoT devices from unauthorized access requests. Compared to centralized CapAC access models, the BlendCAC scheme has the following advantages:

1.  *Decentralized authorization*: leveraging the blockchain technique, the proposed BlendCAC scheme allows domain owners to control their devices and resource without depending on a centralized third authority to establish the trust relationship with unknown nodes; instead, it could define a domain-specific access authorization policy, which is critical to the scalable, heterogeneous and dynamic IoT-based applications;

2.  *Edge computing driven intelligence*: thanks to the blockchain technology, the BlendCAC scheme provides a device driven access control framework that is suitable for the distributed nature of IoT environments. Through transferring power and intelligence from the centralized cloud server to the edge of network, the risk of performance bottleneck and the single point of failure are mitigated, and the smart things are capable of protecting their own resource and privacy by enforcing user-defined security mechanism;

3.  *Fine granularity*: enforcing access right validation on local service providers enables the smart devices to make decisions whether or not to grant access to certain services according to the local environmental conditions. Fine-grained access control with the less privilege access principle prevents privilege escalation, even if an attacker steals a capability token; and

4.  *Lightweight design*: compared to the XML-based language for access control, such as XACML, JSON is a lightweight technology that is suitable for the resource constrained platforms. Given the experimental results, our JSON based capability token structure introduces small overhead on the computation and network performance.

# Conclusions

In this paper, we proposed a decentralized capability-based access control framework leveraging the smart contract and blockchain technology, called BlendCAC, to handle the challenges in access control strategies for IoTs. A concept-proof prototype has been built in a physical IoT network environment to verify the feasibility of the proposed BlendCAC. The BlendCAC model is transcoded to smart contracts and works on the private Ethereum blockchain network. The desktops and laptops serve as miners to maintain the sanctity of transactions recorded on the blockchain, while Raspberry PI devices act as edge computing nodes to access and to provide IoT-based services. Extensive experimental studies have been conducted and the results are encouraging. It validated that the BlendCAC scheme is able to efficiently and effectively enforce access control authorization and validation in a distributed, trustless IoT network. This work has demonstrated that our proposed BlendCAC framework is a promising approach to provide a scalable, fine-grained and lightweight access control for IoT networks.

While the reported work has shown a wonderful potential, there is still a long way to go to build a complete decentralized security solution for IoTs and edge computing. Deeper insights are expected. Part of our on-going effort is focused on further exploration of the blockchain based access control scheme in real-world applications. Taking the smart surveillance system as a case study, the proposed BlendCAC will be extended to protect network cameras and motion sensors in the novel urban surveillance platform we developed recently .


abstract: Insight into the origin of bulges is saught in this review only from the properties of their stellar populations. Evidence concerning the age of the Galactic bulge stellar population is reviewed first, then the case of the bulge of M31 is discussed. The similarity of bulges and ellipticals is then illustrated, inferring that the problems of the origin of bulges and of the origin of ellipticals may well be one and the same: i.e. the origin of galactic spheroids. In this mood, the current evidence concerning the age of the bulk stellar populations of early-type galaxies is then reviewed, both for low- as well as high-redshift galaxies, and both for cluster as well as field ellipticals. All reported evidence argues for the bulk of stars in galactic spheroids having formed at high redshift, with only minor late additions and small dependence on environment. In the final, more speculative Section an attempt is made to evaluate how current formation scenarios can account for this observational evidence. The role of spheroids in the cosmic star formation and metal enrichment history is also briefly discussed. Finally, some critical questions are asked, which answers may help our further understanding of the formation and evolution of galactic spheroids.
author: Alvio Renzini
European Southern Observatory,
D-85748 Garching b. München, Germany
email@example.com
title: Origin of Bulges

'=11 '=12

# Introduction

Much on our speculations on *how* bulges originated depend on what we believe on *when* they formed. Some scenarios prefer bulges to be young, or middle age, late comers anyway. Others prefer a rapid, early build up of bulges, and push back to very early times the epoch of their formation. For this reason I will mostly concentrate on reviewing evidence on ages, leaving the last section to speculations on origins. While they may provide additional clues, some morphological and dynamical properties – such as bars, ripples, or peanut shapes – are largely ignored in this review.

Section 2 focuses on the Galactic bulge, the one we can study best, and in all details. Next closer bulge to us is that of M31, to which Section 3 is dedicated. No other prominent bulge exists in the Local Group (M33 does not really have a bulge), and Section 4 emphasizes that most bulges of spirals are quite similar to ellipticals, so the problem of bulge ages merges with that of dating ellipticals, and becomes the more general problem of dating *spheroids*. This is the subject of Section 5, i.e. dating spheroids at low, as well as high redshifts. In Section 6 cluster and field early-type galaxies are compared to each other, and Section 7, on speculations, is last.

Overall, a wide body of observational evidences is presented showing that the bulk of stellar populations in galactic spheroids are very old. This is true all the way from the bulge of our own Galaxy to high redshift cluster ellipticals. The main issue that remains open is whether star formation and assembly of spheroids were concomitant events, or whether the bulk of stars formed in smaller entities that then hierarchically coalesced, with this process extending over much of the cosmological time.

# The Age of the Galactic Bulge Relative to the Halo

Dating of bulge stars is complicated by several factors, such as crowding, depth effects, variable reddening, metallicity dispersion, and contamination by foreground disk stars. In an attempt to circumvent some of these limitations Ortolani et al. (1995) have selected the bulge globular clusters NGC 6528 and NGC 6553 for HST study. These clusters are respectively located at $\sim 4^\circ$ and $6^\circ$ from the galactic center, and their overall metallicity \[M/Fe\] is about solar (Barbuy et al. 1999), close to the average for stars in Baade's Window (McWilliam & Rich 1994). Like most other clusters within $\sim 3$ kpc from the Galactic center, they belong to the population of Bulge globular clusters, having the same kinematical properties and metallicity distribution of Bulge stars (e.g. Minniti 1995). (To qualify these clusters as *disk clusters* is clearly a misnomer.)

The upper panel in Fig. 1 shows the CMD of NGC 6553 as sampled by the PC1 chip of WFPC2, that combines good statistics with relatively low differential reddening. Superimposed on it is the mean locus of the CMD of NGC 6528 as sampled by the WF2 chip of WFPC2. The data points of NGC 6553 have been dereddened as indicated in the lower panel so to make its turnoff color equal to that of NGC 6528. Then the CMD of this latter cluster has been shifted vertically to bring its horizontal branch (HB) to coincide with that of NGC 6553. Note that the mean locus of NGC 6528 provides an excellent fit to the NGC 6553 data, from the MS all the way to the tip of the RGB. The virtual identity of the CMD of the two clusters is further demonstrated in the lower panel of Fig. 1, where the men loci of the two clusters are compared to each other.

Also shown in the lower panel of Fig. 1 is the mean locus of the inner halo globular cluster 47 Tuc (\[Fe/H\]=–0.7), which has been shifted in color and magnitude in order to bring into coincidence its HB with that of the two bulge clusters. As can be seen in this figure, the luminosity difference between the HB and the main sequence turnoff of the the Bulge clusters is the same (or even slightly larger) of that of 47 Tuc. This comparison demonstrates that the two Bulge clusters are as old as the halo clusters (to within $\pm\sim 2$ Gyr), and therefore the bulge underwent rapid chemical enrichment to solar abundance and beyond, very early in the evolution of our Galaxy. Due to the *relative* nature of the dating procedure, this conclusion is independent of uncertainties in reddening, distance, and *absolute* age determinations.

The next step in the Ortolani et al. study is represented by an attempt at dating the Bulge *field* stellar population itself, still in a relative fashion with respect to the clusters. Fig. 2 shows that the MS luminosity function of the cluster NGC 6528 is indistinguishable from that of the stars in Baade's Window (the low-reddening bulge field at $\sim 4{\deg}$ from the Galaxy center), that was obtained from observations with the ESO NTT with superb seeing ($0''.4$). From this comparison Ortolani et al. infer that the whole Bulge formed quickly, some 15 Gyr ago (if this is the age of the halo clusters), and set an upper limit of $\sim 10\%$ by number to any intermediate age population in the Bulge. Indeed, a larger proportion of intermediate age stars would have resulted in a shallower fall off of the bulge luminosity function around TO (i.e., for $20.5\ifmmode{\mathrel{\mathpalette\@versim>}}
    \else{$\mathrel{\mathpalette\@versim>}$}\fi V\ifmmode{\mathrel{\mathpalette\@versim>}}
    \else{$\mathrel{\mathpalette\@versim>}$}\fi 19.5$), where instead it coincides with that of the cluster.

Further insight on the formation time scale of the Bulge comes from the detailed abundance studies of Bulge stars. In 12 field K giants McWilliam & Rich (1994) find a moderate $\alpha$-element enhancement (\[Mg/Fe\]$\simeq$\[Ti/Fe\]$\simeq$+0.3, but with \[Ca/Fe\]$\simeq$\[Si/Fe\]$\simeq 0$), moderate r-process element enhancement, while s-process elements appear solar with respect to iron. Barbuy et al. (1999) have analyzed 2 stars in NGC 6553 finding somewhat more enhanced $\alpha$-element overabundance, with \[Na/Fe\]$\simeq$\[Al/Fe\]$\simeq$\[Ti/Fe\]$\simeq$+0.6 and \[O/Fe\]$\simeq$\[Mg/Fe\]$\simeq$\[Si/Fe\]$\simeq$+0.3. Note that different systematcs may go a long way towards explaining the differences between these two studies. General consensus exists on the interpretation of $\alpha$-element and r-process element enhancements as due to a *quick* star formation and metal enrichment, with elements produced by Type II supernovae being incorporated into new stars before the bulk of iron from Type Ia SNs is produced. However, how quick is *quick* remains uncertain. Basically, the bulk of stars must form before the explosion of most SNTa's, but the actual *distribution* of SNIa explosion times following a burst of star formation remains empirically indetermined and theoretically very model dependent (cf. Greggio 1996). According to general wisdom it takes at least $\sim 1$ Gyr for a fair fraction of SNIa to release their iron. If so, at least 90% of the Bulge stars formed within the first Gyr of the object that we now call the Milky Way. In conclusion, the *fossil* evidence tells us that the whole Galactic spheroid is pretty old indeed, and formed on a rather short timescale.

There are important lessons to draw from these conclusions. Our Milky Way is a rather late-type spiral galaxy in a very loose group that is located rather away from major density peaks in the distribution of galaxies. Nevertheless, her whole spheroidal component looks $\sim$ one Hubble time old, from the halo globular clusters all the way to the inner bulge. With a mass of $\sim 2\times 10^{10}\hbox{$M_\odot$}$, the old age for the bulk of the spheroidal population implies an average star formation rate $\sim 20\,\hbox{$M_\odot$}\hbox{${\rm yr}^{-1}$}$ at the epoch of spheroid formation, some 14-15 Gyr ago (having assumed $\sim 10^9$ yr for the duration of the star formation process). This value is as small as the smallest star formation rates of $z\ifmmode{\mathrel{\mathpalette\@versim>}}
    \else{$\mathrel{\mathpalette\@versim>}$}\fi 3$ galaxies (Steidel et al. 1998). Such galaxies have also effective radii of 1-3 kpc (typical of galactic bulges, cf. Giavalisco et al. 1996), and it is rather tempting to speculate that with Lyman-break galaxies one may have caught bulge formation in the action. With the Galactic spheroid accounting for $\sim
20\%$ of the stellar mass of the Milky Way, one can conclude that $\ifmmode{\mathrel{\mathpalette\@versim>}}
    \else{$\mathrel{\mathpalette\@versim>}$}\fi 20\%$ of all stars in our Galaxy have formed "at fairly high redshift".

# The Next Bulge: M31

In ground based and pre-COSTAR HST studies the suspicion had been advanced for the presence in the bulge of M31 of a major intermediate-age component, as suggested by the detection of putative bright AGB stars (e.g. Rich & Mould 1991; Rich, Mould, & Graham 1993; Rich & Mighell 1995; Davidge et al. 1997). However, bright AGB stars ($M_{\rm bol}\simeq -5$) are also produced by old, metal rich globular clusters, such as the Bulge clusters discussed in the previous section (Frogel & Elias 1988; Guarnieri, Renzini, & Ortolani 1997). Moreover, with insufficient angular resolution blends of RGB stars can be mistaken for bright AGB stars (e.g. Renzini 1998b), and the presence of an intermediate age population in the bulge of M31 could not be unquestionably proven with such data.

WFPC2 observations of the bulge of M31 are now becoming available. Jablonka et al. (1999) have obtained deep CMDs for various locations in the bulge of M31, confirming that what on low resolution images appeared as *bright AGB stars* are indeed blends of fainter stars. Fig. 3 shows one of such CMDs, relative to the field in the vicinity of the very metal rich globular cluster G170, located at a projected distance of 1.55 kpc from the center of M31. The CMD of the field near the cluster G177 (at 0.8 kpc from the center) is virtually identical. Perhaps the most stryking aspect of this CMD is the predominance of a fairly homogeneous metal rich population, with the upper RGB bending down in the $V-(V-I)$ CMD due to strong TiO blanketing as typical of metal rich globular clusters (see Fig. 1). Very few metal poor star appear to be present, while the bulk of stars are more metal rich than \[Fe/H\]=–0.25.

In conclusion, there is no evidence for an intermediate age population in the bulge of M31. Its almost uniformly metal rich population points to the presence of a "G-dwarf Problem", which may be a general characteristics of (at least) the inner regions of galactic spheroids (e.g. Greggio 1997). The metallicity distribution of the M31 bulge may provide important insight for understanding the formation process. It rises two intriguing questions: 1) Where are the stars that produced the metals now locked in the bulge stars we see? and 2) Where have the metals produced by this bulge sellar population gone? The tentative answer to the first question is "they are out in the halo of M31", which could be tested extending deep HST imaging to larger galactocentric distances (but see Rich, Mighell, & Neill 1996). The tentative answer to the second question is "they have been ejected out in the IGM by an early galactic wind". If these are the correct answers, then the even more tentative conclusion is that the bulge formed outside-in by dissipative merging and collapse of mostly gaseous pregalactic lumps. with the resulting starburst then ejecting the residual gas and a lot of metals along with it.

# Bulges vs Ellipticals

The properties of bulges are extensively reviewed at this meeting, and there is no point trying to summarize them here. In this section I would like to emphasize only one aspect: the close similarity of the bulges of spiral galaxies with elliptical galaxies. While also this aspect is further illustrated by others at this meeting, Fig. 4 gives a very direct impression of the extent to which bulges are similar to ellipticals (from Jablonka, Martin, & Arimoto 1996), and therefore may share a common origin. The bulk of bulges appear to follow precisely the same Mg$_2-M_{\rm r}$ relation of ellipticals, with just a minority of them (i.e. 5 out of 26 in the Jablonka et al. sample) having Mg$_2$ values appreciably lower than those of ellipticals of similar luminosity. The same similarity also exists between the Mg$_2-\sigma$ relations of bulges and ellipticals (Jablonka et al. 1996).

As well known, the Mg$_2$ index depends on both age and metallicity; actually on both the age and metallicity *distributions*. Therefore, the close similarity of the Mg$_2-M_{\rm r}$ relations argues for spiral bulges and ellipticals sharing a similar star formation history and chemical enrichment. One may argue that origin and evolution have been very different, but differences in age distribution are precisely compensated by differences in the metallicity distributions. This may be difficult to disprove, and I tend to reject this alternative on aesthetic grounds. It requires an unattractive cosmic conspiracy, and I would rather leave to others the burden of defending such a scenario.

In conclusion, it appears legitimate to look at bulges as ellipticals that happen to have a prominent disk around them, or to ellipticals as bulges that for some reason have missed the opportunity to acquire or maintain a prominent disk. Therefore, we can legitimately refer to *spheroids* as the class of objects that includes ellipticals and the bulge+halo component of spirals. In this mood, the problem of the origin of bulges becomes the problem of the origin of spheroids.

# The Epoch of Spheroid Formation

Great progress has been made in recent years towards charting and modeling galaxy formation and evolution. Yet, the origin of the galaxy morphologies, as illustrated by the Hubble sequence, has so far defied a generally accepted explanation. This is also the case for spheroids, i.e. bulges and ellipticals alike, with two quite different scenarios still confronting each other. In one scenario spheroids come from the destruction of pre-existing disks or part of them. In the case of ellipticals, by merging spirals, a widely entertained notion since the original proposal by Toomre (1977). In the case of bulges, by some bar instability randomizing the orbits of stars originally in the inner part of a disk (e.g. Combes et al. 1990; Raha et al. 1991; Hasan, Pfenninger, & Norman 1993), or by being merger remnant ellipticals that managed to re-acquire a new disk. This latter scenario is now motivated by hierarchical clustering cosmologies, and ellipticals are modeled to form through a series of merging events (between spirals) taking place over a major fraction of the cosmological time (e.g. Baugh, Cole, & Frenk 1996; Kauffmann 1996).

The other scenario assumes instead the whole baryonic mass of the galaxy being already assembled at early times in gaseous form, and for this reason it is sometimes qualified as *monolithic*. The original idea can be traced back to the Milky Way collapse model of Eggen, Lynden-Bell, & Sandage (1962), with early examples including the models of Larson (1974) and Arimoto & Yoshii (1987). In this case, the disk of spirals is a late comer, somehow acquired later by a more ancient spheroid.

Through the 1980's much of the debate focused on the age of ellipticals as derived from the integrated spectrum of their stellar populations. In general, advocates of the merger model favored an intermediate age for the bulk of stars in ellipticals, but the matter remained controversial given the well know age-metallicity degeneracy and the crudeness of stellar population models of the time (for opposite views see O'Connell 1986, and Renzini 1986).

A first breakthrough came from noting the tightness of the color-$\sigma$ relation of ellipticals in the Virgo and Coma clusters (Bower, Lucey, & Ellis 1992). This demands a high degree of *synchronicity* in the star formation history of ellipticals, that is most naturally accounted for by pushing back to early times most of the star formation. Making minimal use of stellar population models, this approach provided for the first time a *robust* demostration that at least *cluster* ellipticals are made of very old stars, with the bulk of them having formed at $z\ifmmode{\mathrel{\mathpalette\@versim>}}
    \else{$\mathrel{\mathpalette\@versim>}$}\fi 2$.

The main lines of the Bower et al. argument are as follows. The observed color scatter of cluster ellipticals is related to the age dispersion among them by the relation: $$\delta (U-V) = {\partial (U-V)\over\partial t}(t_{\rm H}-t_{\rm
F})$$ where $t_{\rm H}$ and $t_{\rm F}$ are the age of the "oldest" and "youngest" galaxies, respectively. Here by age one intends the luminosity-weighted age of the stellar populations that constitute such galaxies. The time derivative of the color is obtained from evolutionary population synthesis models, which give $\partial (U-V)/\partial
t\simeq 0.02$ mag/Gyr for $t\simeq 10$. The observed color scatter is $\delta (U-V)\simeq 0.04$ mag, consistent with pure observational errors. Hence, one gets $t_{\rm H}-t_{\rm F}\ifmmode{\mathrel{\mathpalette\@versim<}}
    \else{$\mathrel{\mathpalette\@versim<}$}\fi 0.04/0.02=2$ Gyr, and if the oldest galaxies are 15 Gyr old, the youngest ones ought to be older than 13 Gyr, from which Bower et al. conclude they had to form at $z\ifmmode{\mathrel{\mathpalette\@versim>}}
    \else{$\mathrel{\mathpalette\@versim>}$}\fi 2$. If the oldest galaxies were instead as young as, say 5 Gyr, then the youngest should be older than at least 3 Gyr, which would require a high degree of synchronicity in their formation, which seems unlikely.

Evidence in support of the Bower et al. conclusion has greatly expanded through the 1990's, and is now compelling. This came from the tightness of the fundamental plane relation for ellipticals in local clusters (Renzini & Ciotti 1993), from the tightness of the color-magnitude relation for ellipticals in clusters up to $z\sim 1$ (e.g., Aragon-Salamanca et al. 1993; Taylor et al. 1998; Kodama et al. 1998; Stanford, Eisenhardt, & Dickinson 1998), and from the modest shift with increasing redshift in the zero-point of the fundamental plane, Mg$-\sigma$, and color-magnitude relations of cluster ellipticals (e.g., Bender et al. 1997; Dickinson 1995; Ellis et al. 1997; van Dokkum et al. 1998; Pahre, Djorgovski, & de Carvalho 1997; Stanford, Eisenhardt, & Dickinson 1998; Kodama et al. 1998). All these studies agree in concluding that most stars in ellipticals formed at $z\ifmmode{\mathrel{\mathpalette\@versim>}}
    \else{$\mathrel{\mathpalette\@versim>}$}\fi
3$, though the precise value depends on the adopted cosmology. Fig. 5 illustrates the case of the Mg$-\sigma$ relation for ellipticals in two clusters at $z\simeq 0.37$, while Fig. 6 documents the constancy of the color disperion of cluster ellipticals all the way to $z\sim 1$.

It is worth emphasizing that all these studies follow the methodological approach pioneered by Bower et al. (1992). They focus indeed on the tightness of some correlation amomg the global properties of cluster ellipticals, which sets a robust constraint on their age dispersion as opposed to an attempt to date individual galaxies. Moreover, the move to high redshift offers two fundamental advantages. The first advantage is that looking at high $z$ provides the best possible way (I should say *the* way) of removing the age-metallicity degeneracy. If spheroids are made of intermediate-age, metal rich stars, they should become rapidly bluer and then disappear already at moderate redshift (e.g. Kodama & Arimoto 1997). The observational opportunity of studing galaxies at large lookback times makes quite obsolete attempts at finding combinations of spectral indeces that may distinguish between age and metallicity effects in nearby galaxies. The second advantage is that at high redshift one gains more *leverage*: for given dispersion in some observable one can set tighter and tighter limits to the age dispersion. This comes from the color time derivatives being larger the younger the population. For example, the derivative $\partial (U-V)/\partial t$ is $\sim 7$ times larger at $t=2.5$ Gyr than it is at $t=12.5$ Gyr (e.g. Maraston 1998), and therefore a given dispersion in this rest-frame color translates into a $\sim 7$ times tighter constraint on age and therefore on formation redshift. This is further illustrated also by the case of isolated high redshift ellipticals. For example, Spinrad et al. (1997) found a *fossil* (i.e. passively evolving) elliptical at $z=1.55$ for which they infer an age of at least 3.5 Gyr, hence a formation redshift in excess of $\sim 5$. An even much higher formation redshift may be appropriate for the extremely red galaxy in the NICMOS field of the HDF-South, which spectral energy distribution is best accounted for by an old, passively evolving population at $z\simeq 2$ (Stiavelli et al. 1999).

# Cluster vs Field Spheroids

Much of the evidence discussed in the previous Section is restricted to cluster ellipticals. In hierarchical models, clusters form out of the highest peaks in the primordial density fluctuations, and cluster ellipticals completing most of their star formation at high redshifts could be accommodated in the model (e.g. Kauffmann 1996; Kauffmann & Charlot 1998a). However, in lower density, *field* environments, both star formation and merging are appreciably delayed to later times (Kauffmann 1996), which offers the opportunity for an observational test of the hierarchical merger paradigm.

The notion of field ellipticals being a less homogeneous family compared to their cluster counterparts has been widely entertained, though the direct evidence has been only rarely discussed. Visvanathan & Sandage (1977) found cluster and field ellipticals to follow the same color-magnitude relation, but Larson, Tinsley, & Caldwell (1980) – using the same database – concluded that the scatter about the mean relation is larger in the field than in clusters. More recently, a larger scatter in field versus cluster ellipticals was also found for the fundamental plane relations by de Carvalho & Djorgovski (1992). However, at least part of the larger scatter among field ellipticals certainly comes from their distances being more uncertain than for clusters.

Taking advantage of a large sample ($\sim 1000$) of early-type galaxies with homogenously determined Mg$_2$ index and central velocity dispersion, Bernardi et al. (1998) have recently compared the Mg$_2-\sigma$ relations (which are distance independent!) of cluster and field galaxies, and the result is shown in Fig. 8. As it is evident from the figure, field, group, and cluster ellipticals all follow basically the same relation. The zero-point offset between cluster and field galaxies is $0.007\pm 0.002$ mag, with field galaxies having lower values of Mg$_2$, a statistically significant, yet very small difference. This is in excellent agreement with the offset of $0.009\pm 0.002$ mag, obtained by Jorgensen (1997) using 100 field and 143 cluster galaxies.

Using the time derivative of the Mg$_2$ index from synthetic stellar populations, Bernardi et al. conclude that the age difference between the stellar populations of cluster and field early-type galaxies is at most $\sim 1$ Gyr. The actual difference in the mass-weighted age (as opposed to the luminosity-weighted age) could be significantly smaller that this. It suffices that a few galaxies have undergone a minor star formation event some Gyr ago, with this having taken place preferentially among field galaxies.

The comparison between these empirical findings and the theoretical simulations is somehow complicated by the rather loose way in which cluster, group, and field environment are defined in the observational studies on the one hand, and in the theoretical simulations on the other. For example, in the models of Kauffmann (1996) there is a $\sim
4$ Gyr age difference between model ellipticals now residing in a $10^{15}\hbox{$M_\odot$}$ dark matter halo and those residing in a $10^{12}-10^{13}\hbox{$M_\odot$}$ halo. This age difference would correspond to a difference $\Delta$Mg$_2$$\simeq 0.023$ mag, which Bernardi et al. data exclude at the $\sim 4.5\sigma$ level. However, in Kauffmann & Charlot (1998a) cluster and field are defined as those dark matter halos with circular velocity $V_{\rm c}=1000$ km s$^{-1}$ and $<600$ km s$^{-1}$, respectively, and the age difference between model ellipticals in such two environments is greatly reduced. Empirically, Bernardi et al. have assigned to the field those galaxies that do not belong to known clusters or groups, and one does not know what the average circular velocity is in such environments. Clearly, the problem is to find a common language between observers and model makers, i.e. a common way of defining cluster and field environments before comparing to each other data and simulations.

# Discussion

As documented in the previous sections, compelling evidence now exists for the bulk of stars in galactic spheroids being very old, i.e. formed at redshifts beyond $\sim 3$, and possibly even much beyond this value. This applies to ellipticals and bulges alike, in clusters as well as in the lower desity regions still inhabited by spheroids, including the bulge of our own Galaxy. This is what was expected (actually postulated) in the monolithic collapse scenario, while it appears to be quite at variance with most realizations of the hierarchical merging scenario.

## Monolithic vs Hierarchical

The fact that spheroids are made of old stars does not necessarily invalidate the hierarchical merging paradigm, which actually offers a still unique description on how large galaxies could have been assembled. One possibility to comply with with the observations may be to tune hierarchical models to mimic the monolithic model, by pushing most of the action back to an earlier cosmological epoch. With most of the merging taking place at high redshifts, among still mostly gaseous components, merging itself would promotes widespread starburst activity. The natural observational counterparts of these events may be represented by the Lyman-break galaxies at $z\ifmmode{\mathrel{\mathpalette\@versim>}}
    \else{$\mathrel{\mathpalette\@versim>}$}\fi 3$ (Steidel et al. 1996), where star formation rates could be as high as $\sim 1000\; \hbox{$M_\odot$}\hbox{${\rm yr}^{-1}$}$ (Dickinson 1998). It remains to be explored whether such tuning of algorithms and parameters of the hierarchical model could produce model universes fulfilling all other observational constraints. Alternatively, stars now in spheroids do indeed form at very high redshifts, but they are assembled into big spheroids only at much later times (as favored, e.g. by Kauffman 1996).

One testable prediction of the hierarchical merging model is that – obviously – bigger galaxies form later by assembling smaller pieces, and their stellar populations are appreciably younger than those of smaller galaxies. Therefore, intrinsically brighter galaxies should get bluer at a faster rate with increasing $z$, compared to fainter ones. As a consequence, the color-magnitude, color-$\sigma$, Mg-$\sigma$ and fundamental plane relations should *flatten* with increasing redshift (lookback time). No such effect has been detected yet: the slope of the color-magnitude relation appears to be the same all the way to at least $z\simeq 1$ (see bottom panel in Fig. 6). The predicted flattening is actually a consequence of the postulate that ellipticals are made by merging spirals, with the gas in the disks being turned into stars when the two dark matter halos merge. Hence, in this frame late merging implies late star formation as well. On the other hand, it remains to be seen whether dissipationless merging of gas-free galaxies can produce the spheroids we see at low redshift, with their very high phase-space density. If so, the color-mag and similar relations should actually get *steeper* with increasing redshift.

The other prediction of the hierarchical model is that big galaxies should progressively disappear with increasing redshift, and several claims have been made pros and cons the actual disappearence of elliptical in various redshift surveys. Unfortunately, this approach is less conclusive than it may appear at first sight: when ellipticals are selected following either color or morphological criteria a small residual star formation should suffice to let otherwise old galaxies to drop out of the selected samples, even if their main (spheroidal) body is already in place.

To overcome the intrinsic weakness of this approach, Kauffmann & Charlot (1998b) avoid using either color or morphology criteria, and adopt a pure $K-$band magnitude limited selection criterion. In this way the number evolution of massive galaxies is followed, independently of morphology or trace star formation, hence providing a more fundamental test of the models. Comparing to a $K<19$ sample of galaxies with measured redshift, they conclude that their pure luminosity evolution (PLE) models are excluded by a large margin. Such models would predict $\sim 50\%$ of the galaxies in the sample to be at $z>1$, while only $\sim 10\%$ is observed, hence they argue for number evolution due to merging being at work. The same test can be attempted on the somewhat bigger $K-$band magnitude limited sample of Cohen et al. (1998), which includes 195 objects down to $K=20$. Among these objects, 24 turned out to be stars and for 34 objects no redshift could be determined. Among the residual 137 objects, 21 have $z>1$. The vast majority of objects without a measured redshift are likely to be galaxies at $z>1$, whose strong spectral features have moved out of the range of the optical spectrograph. If so, the sample would have $\sim 21+34=55$ out $\sim 137+34=171$ galaxies at $z>1$, or $\sim 32\%$. Interpolating on Figure 4 in Kauffmann & Charlot (1998b) one can roughly estimate that their PLE model predicts $\sim 60\%$ of galaxies in a $K\le 20$ sample to be at $z>1$, while their hierarchical model predicts $\sim 10\%$. So, the Cohen et al. sample suggests a value that is just midway between the predictions of the two models. Clearly, existing samples are still too small for reaching any firm conclusion, especially when considering that large fluctuations may take place between one pencil beam survey and another due to fluctuations in the sampled large scale structures. For example, Cohen et al. (1998) emphasize that approximately half of the galaxies in their sample lie in five "redshift peaks", likely due to clustering. Therefore, Poisson statistics may be more profitably applied to the number of sampled "structures", rather than to that of galaxies.

## The Role of Spheroids in the Cosmic History of Star Formation

With spheroids containing at least 30% of all stars in the local universe (Schechter & Dressler 1987; Persic & Salucci 1992) or even more (Fukujita, Hogan, & Peebles 1998), one can conclude that at least 30% of all stars – hence $\sim 30\%$ of metals – have formed at $z\ifmmode{\mathrel{\mathpalette\@versim>}}
    \else{$\mathrel{\mathpalette\@versim>}$}\fi 3$ (Renzini 1998a; Dressler & Gunn 1990). This is several times more than suggested by a conservative interpretation of the early attempt at tracing the cosmic history of star formation, either empirically (Madau et al. 1996) or with theoretical simulations (e.g. Baugh et al. 1996). Yet, it is in fine agreement with the recent direct estimates from the spectroscopy of Lyman-break galaxies (Steidel et al. 1998), as well as with sub-mm observations (Hughes et al. 1998), where the cosmic SFR runs flat for $z\ifmmode{\mathrel{\mathpalette\@versim>}}
    \else{$\mathrel{\mathpalette\@versim>}$}\fi 1$, as in one of the options offered by the models of Madau, Pozzetti, & Dickinson (1998).

## The Role of Spheroids in the Metal Enrichment of the Early Universe

The global metallicity of the present day universe is best estimated in clusters of galaxies, where it is $\sim 1/3$ solar. This can be taken as representative of the overall metallicity since clusters and *field* have converted into star and galaxies nearly the same fraction of baryons (Renzini 1997). With $\sim 30\%$ of all stars having formed at $z\ifmmode{\mathrel{\mathpalette\@versim>}}
    \else{$\mathrel{\mathpalette\@versim>}$}\fi 3$, and the metallicity of the $z=0$ universe being $\sim 1/3$ solar, it is straightforward to conclude that the global metallicity of the $z=3$ universe had to be at least $\sim 1/3\times 1/3\sim 1/10$ (Renzini 1998a,c). Damped Ly$_\alpha$ systems (DLA) may offer an opportunity to check this prediction, though they may provide a vision of the early universe that is biased in favor of cold, metal-poor gas that has been only marginally affected by star formation and metal pollution. Metal rich objects that may exist at high redshift, such as giant starbursts that would be dust obscured, metal rich passively evolving spheroids, and the hot ICM/IGM obviously do not enlist among DLAs. Still, these objects may contain much of the metals in the $z\sim 3$ universe as they do in the present day universe. In spite of these limitations the average metallicity of the DLAs at $z=3$ appears to be $\sim 1/20$ solar (Pettini et al. 1997, see their Fig. 4), just a factor of 2 below the expected value from the *fossil evidence*. However, this is still much higher than the extreme lower limit $Z\simeq 10^{-3}Z_\odot$ at $z=3$ as inferred from Ly$_\alpha$ forest observations (Songaila 1997). Ly$_\alpha$ forest material is believed to contain a major fraction of cosmic baryons at high $z$, hence (perhaps) of metals. There is therefore a potential conflict with the estimated global metallicity at $z\simeq 3$, and the notion of Ly$_\alpha$ forest metallicity being representative of the the universe metallicity at this redshift. Scaling down from the cluster yield, such low metallicity was achieved when only $\sim 0.3\%$ of stars had formed, which may be largely insufficient to ionize the universe and keep it ionized up to this redshift (Madau 1998, but see Gnedin & Ostriker 1997). This suggests that Ly$_\alpha$ forest may not trace the mass-averaged metallicity of high redshift universe, and that the universe was very inhomogeneous at that epoch. The bulk of metals would be partly locked into stars in the young spheroidals, partly would reside in a yet undetected hot IGM, a phase hotter than the Ly$_\alpha$ forest phase.

## Open Questions

Several questions remain open at this stage. Some of them can soon get answers from observations, others from new theoretical simulations, or from extracting more information from old ones. Of course, the list of interesting questions could actually be much longer, and include e.g. the origin(s) of all those structural and morphological aspects that have been set deliberately aside in this review.

$\bullet\;$ How can hierarchical models be tuned to produce the uniform age of stars in the

Galactic bulge? ...

$\bullet\;$ and the uniformity of stellar metallicity in the bulge of M31?

$\bullet\;$What fraction of *"ellipticals"* would belong to clusters, groups, and field in simulations

of galaxy formation?

$\bullet\;$ How much number evolution of spheroids has taken place between $z=1$ and $z=0$?

$\bullet\;$ What is the redshift distribution of a fair and complete sample of $K\le 20$ galaxies?

$\bullet\;$ Is the fraction of spheroids formed by merging *spirals* very large or very small?

$\bullet\;$ At which redshift do color-magnitude (and analogous) relations for ellipticals begin to

flatten? Do they flatten at all?

$\bullet\;$ At $z\simeq 1$ do global relations for ellipticals in the field differ from those of galaxies in

clusters, and if so by how much?

$\bullet\;$ Are Lyman-break galaxies spheroids in formation? What is their mass?

$\bullet\;$ What is the global metallicity of the universe at $z=3$?

$\bullet\;$ Does an early assembly of bulges help forming the right disks?

$\bullet\;$ Is the early universe re-ionized and maintained ionized by forming spheroids?

It is my feeling that it will not take much before having fairly secure answers to most of these questions.

*Acknowledgements*: I would like to thank Ralf Bender, Marc Dickinson, Marijn Franx and Pascale Jablonka for their kind permission to reproduce here some of the figures from their papers. I would also like to thank the Space Telescope Science Institute for its hospitality during the meeting.